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SECTION  A 
INTRODUCTION 


1.  WHAT  IS  A  HUMAN  SYSTEMS  INTEGRATION  (HSU  PROCESS  MODEL?  A 
"process"  can  be  defined  as  a  series  of  actions,  changes,  or  functions  that  bring  about  an  end 
result.  An  HSI  Process  Model  describes  those  specific  actions  that  must  be  accomplished  in 
each  domain  across  the  seven  Coast  Guard  acquisition  phases  to  ensure  that  human  issues  are 
identified,  addressed,  and  managed  throughout  the  design,  development,  and  support  of  a  new 
materiel  system. 

2.  BACKGROUND.  The  HSI  Program  Requirements  Document,  developed  during  Task  A 
of  this  project,  introduced  the  Coast  Guard  to  the  many  advantages  of  the  HSI  Program  and  the 
substantial  cost  and  performance  benefits  available  by  implementing  HSI  in  the  Coast  Guard 
acquisition  system.  A  number  of  deficiencies  were  identified  in  previous  acquisitions  that  could 
have  been  minimized  or  avoided  if  the  principles  of  the  HSI  Program  had  been  followed.  Task 
A  has  clearly  established  the  need  for  an  effective  HSI  Program  in  the  Coast  Guard  acquisition 
process. 

Development  of  the  Coast  Guard  HSI  Process  Model  in  Task  B  is  the  next  logical  step  to  further 
refine  the  HSI  Program  for  Coast  Guard  evaluation.  This  model  provides  the  next  level  of  detail 
in  describing  how  the  Coast  Guard  should  design  and  manage  each  domain  to  achieve  the 
objectives  of  HSI  within  the  boundaries  of  the  acquisition  process.  The  model  recommends  a 
series  of  action  steps  that  define  a  specific  process  in  each  domain,  and  the  total  processes  have 
been  tailored  to  meet  requirements  and  timing  of  the  seven  phases  and  four  Key  Decision  Points 
(KDPs)  in  the  Coast  Guard  acquisition  system. 

The  HSI  Process  Model  has  been  designed  using  the  best  features  of  the  Department  of  Defense 
(DoD)  HSI  Programs  developed  over  the  past  10  to  15  years  by  the  individual  DoD  Military 
Services.  This  allows  the  Coast  Guard  to  take  advantage  of  lessons  learned  from  these  previous 
development  efforts  and  to  avoid  much  of  the  costly  and  time-consuming  false  starts  associated 
with  developing  a  new  program  from  the  ground  up.  In  developing  this  HSI  Process  Model, 
we  have  tailored  proven  techniques  and  processes  to  the  specific  Coast  Guard  needs  in  each 
domain,  thereby  creating  a  uniquely  Coast  Guard  HSI  Program. 

Accordingly,  this  document  describes  the  basis  for  the  HSI  Process  Model,  as  well  as  the 
methodologies  and  specific  processes  recommended  to  fully  integrate  HSI  into  the  Coast  Guard 
acquisition  process.  Following  this  introduction,  Section  B  will  describe  the  DoD  HSI  programs 
used  and  the  rationale  for  selecting  each  process  as  the  basis  for  the  Coast  Guard  HSI  Process 
Model.  Section  C  details  the  recommended  management  structure  needed  to  manage  HSI 
through  each  phase  of  the  acquisition  process.  Section  D  describes  the  processes  recommended 
as  the  Coast  Guard  model -in  implementing  HSI,  including  the  data  bases  required,  content  of 
the  essential  Front-End  Analysis  (FEA),  how  to  write  hardware/software  contractor  Requests  for 
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Proposals  (RFPs)  to  include  HSI,  and  a  discussion  of  cost  determination;  Section  D  concludes 
with  a  description  of  the  recommended  processes  in  each  HSI  domain.  Section  E  discusses  how 
HSI  fits  into  alternative  acquisition  strategies,  including  the  tailoring  of  traditional  full 
development  procurements,  materiel  changes,  non-developmental  item  acquisitions,  and 
streamlining  in  all  strategies.  The  document  concludes  with  recommendations  in  Section  F  for 
assignment  of  specific  Headquarters  Staff  organizations  to  manage  implementation  of  HSI.  A 
list  of  references  is  included  at  Appendix  A  and  acronyms  at  Appendix  B.  Additionally,  a 
description  of  HSI  in  the  Department  of  Defense  and  the  Military  Departments  is  included  as 
an  Attachment  at  the  rad  of  this  document. 
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SECTION  B 

DESIGN  OF  THE  MODEL 


1  DFPARTMF-NT  of  defense  military  services  human  systems 

INTEGRATION  (HSD  MODELS.  We  reviewed  the  major  DoD  Military  Service  HSI 
Models,  analyzed  the  various  management  and  domain  processes  they  use,  and  evaluated 
how  well  the  strongest  of  those  processes  fit  with  the  Coast  Guard  acquisition  system  in 
developing  a  unique  Coast  Guard  HSI  Process  Model.  We  also  identified  DoD  model 
commonalities,  primary  strengths  of  the  collective  models,  and  strengths/weaknesses  of  the 
individual  DoD  models. 

1.1  Major  HSI  Models  Reviewed.  Since  February  1991,  all  DoD  Services  have  been 
required  to  include  all  five  domains  in  each  system  acquisition.  The  following  HSI 
Modelswere  reviewed. 

a.  Army  Manpower  and  Personnel  Integration  (MANPRINT)  Program.  Army 
pioneered  development  of  six  MANPRINT  domains  and  was  the  model  on 
which  DoD  chose  to  base  the  HSI  Program.  Among  the  DoD  Services, 
MANPRINT  has  the  most  mature  process  in  the  Human  Factors  Engineering 
(HFE)  and  System  Safety/Health  Hazard  (SS/HH)  domains. 

b.  Naw  Military  Hardware /Manpower  Integration  (HARDMAN)  Program. 
HARDMAN  is  designed  to  determine  Manpower,  Personnel,  and  Training 
(MPT)  domain  requirements  only.  HFE  and  SS/HH  domains  have  been 
included  in  Navy  Procurements  for  the  past  several  years  by  some  Navy 
Systems  Commands  for  acquisitions  in  their  functional  areas.  Unfortunely, 
not  all  Navy  functional  areas  have  been  included,  and  the  HSI  domains  have 
not  been  integrated.  Secretary  of  the  Navy  (SECNAV)  Instruction  5000.2A 
has  recently  been  approved  to  implement  defense  acquisition  management 
policies  and  procedures.  This  instruction  reaffirms  use  of  the  HARDMAN 
methodology  for  MPT  domains  and,  additionally,  requires  that  HFE  and 
SS/HH  domains  be  integrated  into  all  system  acquisitions. 

c.  Air  Force  Integrated  Manpower.  Personnel,  and  Comprehensive  Training  and 
■Safety  (IMPACTS)  Program.  This  program  is  aimed  at  standardizing  and 
integrating  all  HSI  activity.  Over  the  past  several  years,  each  individual  Major 
Command  in  the  Air  Force  has  developed  their  own  acquisition  processes. 
This  has  resulted  in  little  standardization  and  an  acquisition  system  with 
components  that  are  not  integrated.  The  process  has  generally,  but  sometimes 
inconsistently,  used  all  HSI  domains  and  is  more  automated  than  the  other 
service  programs. 
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d.  U.S.  Marine  Corps.  The  Marines  also  has  an  HSI  program,  but  it  is  not 
substantially  different  from  the  Navy  program. 

1.2  Program  Commonality.  In  evaluating  the  effectiveness  of  each  Services'  HSI  Model, 
we  found  the  following  commonality  between  the  models. 

a.  An  identifiable  program 

b.  Specific  governing  directives 

c.  The  manpower  and  personnel  communities  have  significant  roles  in  the  HSI 
program 

d.  Program/Project  Managers  are  tasked  to  include  HSI  in  design  of  major 
acquisition  projects 

e.  Comparability  analysis  is  the  primary  analytical  technique  used 

f.  Training  is  provided  for  HSI  analysts 

g.  Programs  are  all  relatively  new 

h.  Programs  are  growing,  but  at  different  rates 

1.3  Primary  Strengths  in  DoD  HSI  Models.  Each  DoD  HSI  model  varies  in  how  much  it 
contributes  to  the  acquisition  process.  Following  are  the  primary  elements  of  strength  that 
the  collective  programs  exhibit. 

a.  Perhaps  the  most  critical  strength  to  long-term  success  is  strong,  sustained 
support  for  HSI  from  the  organizations  executing  the  program.  Both  senior 
level  and  grass  roots  support  are  important.  Senior-level  support  facilitates 
quick  program  starts,  but  grass  roots  support  sustains  the  program  over  the 
long  term. 

b.  Adequate  resource  support  is  critical  in  both  funding  and  staff  personnel. 
This  is  especially  true  in  establishing  the  initial  HSI  Program  and  in 
coordinating  Front-End  Analysis  (FEA).  Without  this  support,  HSI  cannot 
impact  system  design. 

c.  Strong  technical  programs  and  sound  program  strategy  produce  credible 
results  that  avoid  costly  alterations  and  redesigns. 

d.  Programs  that  are  well  documented  down  to  an  analyst  level  of  detail  prevent 
the  analyst  from  "reinventing  the  wheel"  on  each  acquisition. 
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e.  Mandatory  use  of  HSI  principles  in  all  acquisitions  is  necessary  and  must  be 
enforced  to  prevent  redistribution  of  HSI  resources  to  other  priorities. 

f.  Strong  HSI  Program  identity  is  a  must,  and  it  should  be  separate  from  the 
Integrated  Logistics  Support  (ELS)  organization  (although  products  and  data 
are  coordinated  with  ELS). 

g.  The  manpower  and  personnel  community  must  have  meaningful  roles.  These 
two  communities  are  the  traditional  institutional  representatives  of  Manpower, 
Personnel,  and  Training. 

h.  A  strong  commitment  to  HSI  in  source  selection  and  contracting  specifications 
is  required  to  send  a  clear  message  to  industry  that  the  Coast  Guard  is  serious 
about  wanting  HSI  to  influence  system  design. 

1.4  Strengths  and  Weaknesses  in  DoD  Service  HSI  Models.  The  systemic 
strengths/weaknesses  discussed  here  are  based  on  needs  of  the  Service,  how  well  each 
program  meets  DoD  requirements,  and  the  compatibility  of  these  programs  with  the  Coast 
Guard  acquisition  process. 

1.4.1  Army  MANPRTNT  Program.  This  is  the  most  complete  and  generally  recognized  as 
the  strongest  overall  HSI  Program  in  DoD.  In  maturity,  MANPRINT  is  9  years  old  in 
name,  8  years  old  in  planning,  7  years  old  in  training,  and  6  years  old  in  documentation. 
A  more  complete  description  of  the  MANPRINT  Program  is  included  in  Appendix  C. 

1.4.1. 1  Critique  of  MANPRINT  Systemic  Processes, 
a.  MANPRINT  Program  Strengths. 

(1)  There  has  been  strong  senior  level  support  from  program  inception  in 
1983  (program  was  officially  promulgated  in  1984),  and  popular  grass 
roots  support  as  well. 

(2)  In  evaluation  criteria  for  Request  for  Proposal  (RFP)  source  selections, 
MANPRINT  has  been  designed  as  a  separate  major  area  having  equal 
weight  with  technical,  management,  and  cost  in  the  evaluation  process. 

(3)  Requirements  of  MANPRINT  in  RFPs  have  impacted  the  award  of 
several  major  contracts.  This  commitment  has  industry  attention. 

(4)  MANPRINT  has  strong  program  identification  separate  from  ILS  and 
has  provided  a  meaningful  role  for  the  manpower  and  personnel 
communities. 
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(5)  The  program  is  sponsored  by  a  single  organization  at  the  Headquarters 
level. 

(6)  MANPRINT  is  managed  through  each  acquisition  by  a  MANPRINT 
Joint  Working  Group  (MJWG)  co-chaired  by  the  Combat  Developer 
(the  user  or  user  representative)  and  the  Materiel  Developer  (the 
Army  Materiel  Command)  assigned  to  design  and  develop  the  new 
materiel.  MJWG  is  Army's  executive  agent  responsible  for  identifying, 
analyzing,  resolving,  and  documenting  all  HSI  issues  during  system 
acquisition.  This  management  process  brings  together  all  the  right 
organizations  to  focus  Army  expertise  in  solving  each  specific 
acquisition's  problems. 

(7)  MANPRINT  domain  expertise  is  institutionalized  among  several  large 
Army  organizations.  This  permits  these  organizations  to  support  the 
HSI  Program  with  required  expertise  as  a  normal  part  of  their  daily 
business. 

(8)  The  MANPRINT  Program  starts  at  project  initiation  and  makes  major 
inputs  in  all  domains  to  design  and  development  of  each  new 
acquisition.  The  Program  also  provides  a  systematic  approach  to 
developing  affordable  and  supportable  life-cycle  MPT  requirements. 

(9)  Army  institutional  organizations  maintain  HSI  lessons  learned  and 
other  applicable  documentation  external  to  individual  acquisitions. 
They  also  maintain  historical  records  of  each  acquisition. 

(10)  Army  has  designated  Director  of  Information  Systems  for  Command, 
Control,  Communications,  and  Computers  (DISC-4)  to  establish 
MANPRINT  policy  and  guidance  for  the  acquisition  of  management 
information  systems. 

b.  MANPRINT  Program  Weaknesses. 

(1)  Under-funding  of  Front-End  Analyses  continues  to  be  a  problem.  This 
is  primarily  because  of  a  lack  of  appreciation,  among  people 
responsible  for  funding  FEA,  for  the  critical  role  FEA  plays  in  the  HSI 
Program  during  the  very  earliest  phases  of  the  new  acquisition. 
Unfortunately,  if  the  window  of  opportunity  to  make  meaningful  input 
to  major  system  documentation  that  drives  the  design  process  is 
missed,  there  are  no  inexpensive  ways  to  catch  up  later  in  the 
acquisition. 
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(2)  The  validity  of  analytical  techniques,  adequacy  of  data,  and 
identification  of  essential  elements  of  information  varies  by 
MANPRINT  functional  area  and  should  be  improved  in  most  areas. 

1.4. 1.2  Critique  of  MANPRINT  Domain  Processes. 

a.  Human  Fartnrs  Engineering.  MANPRINT  has  the  oldest  HFE  program  and 
the  most  HFE  experience  on  actual  procurements  of  any  DoD  program. 

(1)  The  HFE  domain  is  fully  integrated  into  system  and  design  engineering 
for  maximum  impact  on  system  design.  HFE  also  functions  as  the  lead 
domain,  coordinating  with  other  domain  specialists  to  find  solutions  to 
HSI  problems  that  may  impact  system  design,  and  then  coordinating 
the  recommended  solutions  with  system  and  design  engineers  to  make 
corrections  in  the  proposed  design. 

(2)  HFE  work  in  acquisitions  is  mostly  done  in-house  by  the  Army  Human 
Engineering  Laboratory  or  the  Army  Research  Institute.  This 
promotes  continuity  from  one  procurement  to  the  next  and  aids  in 
developing  a  comprehensive  lessons  learned  data  base  for  use  in 
improving  HFE  inputs  to  future  acquisitions. 

(3)  MANPRINT  was  the  first  DoD  system  to  recognize  the  impact  of 
human  performance  on  total  system  reliability.  The  Army  system  has 
pioneered  development  of  HFE  applications  to  military  hardware 
design.  Over  time,  this  system  has  developed  into  a  complete  program, 
covering  all  aspects  of  HFE  from  development  of  human  performance 
criteria  and  constraints  to  testing  the  design  for  performance  shortfalls. 

(4)  The  MANPRINT  HFE  domain  has  not  been  applied  to  vessels  the  size 
of  Coast  Guard  cutters  and  generally  not  to  larger  aircraft. 

b.  System  Safety  /Health  Hazards.  MANPRINT  splits  System  Safety  and  Health 
Hazards  into  two  distinct  domains  (for  a  total  of  six  domains).  This  is 
primarily  because  there  are  two  separate  Army  institutional  organizations 
responsible  for  these  functional  areas:  the  Army  Safety  Center  handles 
System  Safety,  while  the  Army  Surgeon  General  is  responsible  for  Health 
Hazards. 

(1)  MANPRINT  primarily  uses  the  DoD  Military  Standard  882B,  entitled 
System  Safety  Program  Requirements,  to  meet  the  needs  of  both 
System  Safety  and  Health  Hazards. 


B-5 


(2)  The  SS  and  HH  domains  in  MANPRINT  are  relatively  mature  and 
offer  a  complete  program  from  identification  of  SS/HH  objectives  and 
review  of  lessons  learned  to  test  and  evaluation  of  the  new  design. 
Both  SS  and  HH  criteria  are  applied  to  all  design  changes  to  ensure 
the  final  design  is  safe  and  hazard  free. 

c.  Manpower.  Personnel,  and  Training.  While  each  of  these  domains  is  distinct, 
MANPRINT  intertwines  MPT  into  the  process  such  that  it  is  expedient  to 
evaluate  the  MPT  domains  as  part  of  a  single  process. 

(1)  The  strongest  feature  of  the  MANPRINT  MPT  process  is  development 
of  a  Target  Audience  Description  (TAD)  to  tie  the  HSI  process 
specifically  to  the  system  design.  This  TAD  is  a  direct  human  criteria 
input  to  the  hardware/software  contractor  who  will  design  and  build 
the  new  acquisition.  The  TAD  describes  the  capabilities  and 
limitations  of  the  people  who  will  be  available  to  operate,  maintain, 
train,  and  otherwise  support  the  new  procurement  when  fielded.  Not 
only  are  these  design  criteria  passed  officially  to  the  contractor,  but  the 
new  design  is  tested  and  evaluated  to  ensure  the  design  meets  the 
human  specifications.  If  not,  the  contractor  will  have  to  redesign  the 
system  until  the  human  criteria  are  met. 

(2)  All  commands  in  the  Army  with  any  responsibility  for  MPT  in 
acquisitions  are  brought  together  by  the  MANPRINT  Joint  Working 
Group.  The  MJWG  is  a  way  to  focus  Army  institutional  expertise  on 
solving  MPT  problems  in  individual  procurements.  MJWG 
management  of  the  MPT  process  through  all  phases  of  each  acquisition 
is  another  strong  feature  of  the  MANPRINT  program. 

(3)  MANPRINT  MPT  analytical  tools  are  data  intensive,  requiring 
considerable  time,  effort,  and  cost  before  the  models  can  be  run.  Then 
several  iterations  are  sometimes  required  before  a  final  output  is 
completed. 

1.4.2  Navy  HARDMAN  Program.  The  Navy  HARDMAN  Program  is  the  oldest  MPT 
program  in  DoD  having  originated  in  its  initial  form  in  1976.  The  program  has  a  reputation 
for  having  sound  analytical  approaches  and  a  systematic  process  for  determining  life-cycle 
MPT  requirements  in  the  design  of  new  procurements.  A  description  of  the  Navy 
HARDMAN  Program,  plus  the  Navy  program  to  include  Human  Factors  Engineering  and 
System  Safety /Health  Hazard  domains  in  system  acquisitions,  is  presented  in  Appendix  D. 
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1 .4.2.1  Critique  of  Naw  HARDMAN  Svstemic  Processes. 


a.  HARDMAN  Program  Strengths. 

(1)  HARDMAN  has  valid  and  proven  analytical  techniques  in  the  MPT 
domains.  This  solid  technical  program  produces  sound,  credible  MPT 
life-cycle  requirements. 

(2)  HARDMAN  provides  systematic  approaches  to  defining  MPT  life-cycle 
requirements  in  each  acquisition. 

(3)  Navy  Systems  Commands  have  been  using  and  perfecting  HFE  and 
SS/HH  techniques  in  ships  and  aircraft  for  the  past  several  years. 
SECNAVINST  5000.2A  formalizes  and  integrates  an  on-going  process. 

(4)  HARDMAN  Methodology  focuses  Navy  institutional  expertise  on 
solving  MPT  issues  in  individual  acquisitions. 

(5)  HARDMAN  provides  a  meaningful  role  for  the  manpower  and 
personnel  communities. 

(6)  This  program  is  well  documented  down  to  the  analyst  level  of  detail. 

b.  HARDMAN  Program  Weaknesses. 

(1)  High-level  and  Systems  Command  support  for  HARDMAN  has  been 
weak  and  inconsistent.  HFE  and  SS/HH  has  considerable  grass  roots 
support  but  is  primarily  driven  at  higher  levels  by  DoD  requirements. 

(2)  Mandatory  use  of  HARDMAN  in  all  acquisitions  has  not  been 
enforced.  Systems  Command  PMs  determine  timing,  funding,  and 
depth  of  HARDMAN  analyses,  but  may  be  motivated  to  trade-off 
HARDMAN  resources  in  favor  of  other  cost,  schedule,  and 
performance  needs.  Funding  for  Front-End  Analysis  has  been 
insufficient,  primarily  for  this  reason. 

(3)  HARDMAN  is  not  well  integrated  with  system/design  engineering  and 
concentrates  more  on  identifying  MPT  requirements  of  the  completed 
system  than  on  impacting  system  design. 

(4)  Responsibility  for  HARDMAN  is  still  fragmented  with  no  single 
organization  responsible  for  the  entire  program. 
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1. 4.2.2  Critique  of  Naw  HARDMAN  Domain  Processes.  The  HARDMAN  Methodology 
focuses  on  the  MPT  domains  and  does  not  address  Human  Factors  Engineering  or  System 
Safety/Health  Hazards.  In  response  to  DoD  Instruction  5000.2  dated  February  23,  1991, 
the  Navy  has  issued  SECNAV  Instruction  5000.2A  that  requires  HFE  and  SS/HH  to  be 
included  in  system  design.  The  SYSCOMs  have  used  HFE  and  SS/HH  inputs  to  some 
degree  in  most  procurements  for  the  past  few  years.  The  following  paragraphs  describe  the 
status  of  the  HSI  domains  in  Navy  acquisition  with  a  view  toward  potential  benefits  to  the 
Coast  Guard  in  starting  up  an  HSI  Program. 

a.  Human  Factors  Engineering.  This  domain  has  been  discussed  in  Navy 
acquisition  directives  in  the  past,  but  HFE  has  not  been  particularly 
emphasized  in  most  Navy  procurements.  Both  the  Naval  Air  and  Naval  Sea 
Systems  Commands  have  used  HFE  in  the  design  and  development  of  aircraft 
and  ships.  Both  Systems  Commands  have  developed  process  models  to  guide 
the  integration  of  HFE  specifically  into  ship  and  aircraft  designs.  Neither 
SYSCOM  is  using  a  complete  HFE  program  to  include  an  HFE  plan  for  each 
acquisition,  analyses  to  determine  optimum  man-machine  interface,  test  and 
evaluation  of  the  completed  design,  and  follow-up  to  ensure  all  required  HFE 
changes  have  been  incorporated  in  the  deployed  system.  HFE  has  not  been 
a  significant  part  of  the  source  selection/contract  award  process  in  Navy 
acquisitions.  Some  lessons  learned  experience  has  been  documented  from 
these  HFE  applications. 

b.  System  Safety /Health  Hazards.  Navy  acquisition  directives  have  required  that 
a  minimum  SS/HH  program  be  included  in  system  acquisitions.  This  has 
been  done  by  requiring  hardware/software  contractors  to  comply  with  Military 
Standard  882B.  In  addition,  some  segments  of  the  Navy  (such  as  the 
submarine  force)  have  been  on  the  leading  edge  of  safety  innovation  for 
several  years.  Lessons  learned  have  been  documented  for  ship  and  aircraft 
procurements. 

c.  Manpower.  Personnel,  and  Training.  These  domains  have  been  required  by 
Navy  acquisition  directives  as  part  of  the  Integrated  Logistics  Support  Plan 
(ILSP).  HARDMAN  Methodology  is  used  by  the  PM  staff  (or  by  contractor) 
to  determine  MPT  requirements  for  each  acquisition.  The  HARDMAN 
directive  was  developed  and  is  sponsored  by  the  Chief  Naval  Operations 
(CNO)  staff  office  responsible  for  MPT  (i.e.,  OP-01).  Since  OP-01  has  no 
responsibility  for  acquisition,  the  Methodology  is  focused  on  determining  MPT 
requirements  for  the  completed  acquisition,  rather  than  emphasizing 
manpower  savings  through  better  engineering  design  or  other  ways  to  impact 
system  design.  To  offset  this  bias  in  the  Methodology,  close  coordination  is 
required  between  the  Program  Manager's  staff  (or  contractor)  conducting  the 
HARDMAN  Methodology  and  the  SYSCOM  design  engineering  organizations 
responsible  for  system  design. 
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The  HARDMAN  Methodology  uses  the  Navy  Training  Plan  (NTP)  process 
to  formally  approve  all  MPT  requirements  for  each  acquisition.  The  Program 
Manager's  staff  (or  contractor)  documents  the  manpower  and  personnel 
requirements  in  the  NTP  and  uses  them  as  inputs  to  develop  the  training 
requirements.  The  documented  MPT  requirements  from  the  Program 
Manager's  staff  are  approved  by  the  Navy  institutional  organization 
responsible  for  MPT  (i.e.,  OP-01).  The  approved  NTP  is  used  by  OP-01  to 
provide  life-cycle  MPT  support  to  the  new  acquisition. 

1.4.3  Air  Force  IMPACTS  Program.  This  program  is  a  follow-on  to  the  Readiness 
Achieved  Through  Manpower,  Personnel,  and  Requisite  Training  and  Safety  (RAMPARTS) 
Program. 

1.4.3.1  Critique  of  Air  Force  IMPACTS  Systemic  Processes. 

a.  IMPACTS  Program  Strengths. 

(1)  A  model  organization  has  been  established  at  Wright  Patterson  Air 
Force  Base  to  institutionalize  IMPACTS  at  the  engineering  level.  This 
is  a  strong  point  because  HSI  must  impact  system  design  through  the 
engineering  organization  responsible  for  the  design.  Accordingly,  most 
HSI-to-engineer  interface  problems  would  be  solved  by 
institutionalizing  HSI  at  the  engineering  level. 

(2)  The  IMPACTS  Program  includes  advanced  models  in  most  functional 
areas.  These  automated  models  have  been  developed  over  a  number 
of  years  and  are  quite  mature. 

b.  IMPACTS  Program  Weaknesses. 

(1)  Air  Force  HSI  is  not  integrated  and  approaches  are  not  cohesive  or 
consistent.  Each  Major  Command  has  developed  its  own  models  and 
procedures.  IMPACTS  is  meant  to  standardize  and  integrate  the  HSI 
Program. 

(2)  High-level  support  for  IMPACTS  has  been  weak.  The  IMPACTS 
directive  has  been  in  draft  since  October  1988  and  was  only  recently 
approved. 

(3)  Analytical  models  are  non-standard,  and  their  use  is  decentralized  and 
inconsistent. 

1.4.3 .2  Critique  of  Air  Force  IMPACTS  Domain  Processes.  When  the  Air  Force  recently 
approved  the  IMPACTS  Program  directive,  we  found  it  to  have  insufficient  detail  to 
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adequately  critique  how  the  IMPACTS  Program  handles  individual  domain  processes. 
Consequently,  our  recommendations  for  the  Coast  Guard  HSI  Process  Model  does  not 
include  any  specific  Air  Force  Model  strengths. 

1.5  Rationale  for  Selecting  the  Coast  Guard  Model  in  Each  Domain.  Based  on  our  review 
of  existing  models,  we  have  developed  a  unique  for  Coast  Guard  Process  Model  using  the 
following  criteria: 

a.  Specific  characteristics  or  elements  providing  the  best  fit  for  tailoring  HSI  to 
the  Coast  Guard  acquisition  process  with  the  least  disruption,  while  retaining 
maximum  effectiveness. 

b.  Strengths  and  weaknesses  of  existing  HSI  models. 

c.  Models  offering  the  most  cost  saving/cost  avoidance  and  best  timeliness. 

d.  Coast  Guard  similarities  in  materiel  systems,  personnel  structure,  operating 
environment,  and  maintenance/training  requirements. 


B-10 


SECTION  C 

COAST  GUARD  MANAGEMENT  SYSTEM 


TABLE  OF  CONTENTS 

PARAGRAPH  PAGE 

1.  INTRODUCTION . C-l 

2.  COAST  GUARD  HSI  MANAGEMENT  SYSTEM  OBJECTIVES . C-l 

3.  DESCRIPTION  OF  RECOMMENDED  MANAGEMENT  STRUCTURE .  C-2 

3.1  OHSIP  Management  Responsibilities  . C-3 

3.2  HSI  System  Management  Plan  (HSISMP)  . C-6 

3.3  HSI  Reviews  and  Assessments  . C-l 

4.  INTERFACES  NECESSARY . C-l 

4. 1  Interface  Between  the  Office  Responsible  for  the  HSI  Program 

and  the  Program  Sponsor  (PS)  . C-8 

4.2  Interface  Between  OHSIP  and  the  Project  Manager . C-ll 

4.3  Interface  Between  OHSIP  and  the  Manpower  Proponent  in  the  Office  of 

the  Chief  of  Staff . C-14 

4.4  Interface  Between  OHSIP  and  the  Personnel  Proponent  in  the  Office  of 

Personnel  and  Training . C-15 

4.5  Interface  Between  OHSIP  and  Training  Proponent  in  the  Office  of 

Personnel  and  Training . C-l 7 

4.6  Interface  Between  OHSIP  and  the  SS/HH  Proponent  in  the  Office  of  Health 

and  Safety . C-17 

4.7  Interface  Between  OHSIP  and  the  Human  Factors  Engineering 

Proponent . . C-l  8 

4.8  Interface  Between  OHSIP  and  the  ILS  Manager . C-19 

LIST  OF  EXHIBITS 

EXHIBIT  PAGE 


C-l.  Tools  Used  to  Manage  HSI  in  Individual  Coast  Guard  Acquisitions .  C-3 

C-2.  Interfaces  Required  to  Execute  the  HSI  Program . C-8 


C-i/C-ii 


SECTION  C 

COAST  GUARD  MANAGEMENT  SYSTEM 


1.  INTRODUCTION.  This  section  describes  how  the  recommended  management  process 
should  work  in  the  Coast  Guard  acquisition  system.  The  management  system  described  here  is 
the  day-to-day  activity  required  to  manage  Human  Systems  Integration  concerns  throughout  an 
individual  acquisition.  The  philosophy  of  the  Coast  Guard  HSI  Program  should  be  to  require 
industry  and  the  acquisition  system  to  answer  the  following  question  on  each  acquisition,  "Can 
this  Coast  Guardsman  with  this  training  perform  these  tasks  to  these  standards  under  these 
conditions?" 

We  begin  by  listing  the  objectives  the  Coast  Guard  HSI  management  system  should  strive  to 
achieve.  Then  we  describe  how  the  management  structure  will  work,  including  the  specific 
duties  performed  by  the  office  responsible  for  the  HSI  Program  (OHSIP),  the  System 
Management  Plan,  and  HSI  Reviews  and  Assessments.  We  end  this  section  with  a  discussion 
of  the  various  interfaces  necessary  to  ensure  a  smooth  and  orderly  implementation  of  the  HSI 
Program. 

2.  COAST  GUARD  HSI  MANAGEMENT  SYSTEM  OBJECTIVES.  In  managing  HSI 
through  each  acquisition,  the  management  system  is  striving  to  achieve  the  following  objectives: 

a.  Include  HSI  considerations  as  a  major  "Source  Selection  Criteria"  to  be  used  in 
evaluating  contractor  proposals. 

b.  Develop  equipment  that  permits  human-materiel  interaction  within  human 
physiological  tolerance  limits,  training  time,  personnel  aptitudes  and  skills. 

c.  Develop,  maintain,  and  use  data  bases  containing  human  factors,  human 
performance,  manpower,  personnel,  training,  system  safety,  and  health  hazard 
information.  This  includes  lessons  learned  in  each  domain  and  a  historical  file 
for  use  in  future  acquisitions. 

d.  Conduct  Front-End  Analysis  early  enough  in  the  process  to  develop  HSI 
constraints  in  each  domain,  performance  criteria,  and  other  inputs  to  all  major 
program  documentation,  including  the  Mission  Need  Statement,  strategy 
objectives  for  the  Acquisition  Plan,  Preliminary  Operational  Requirements 
Document,  Project  Management  Plan,  Test  and  Evaluation  Master  Plan,  and 
Integrated  Logistic  Support  Plan  (ISLP). 

e.  Provide  HSI  inputs  in  all  appropriate  parts  of  Requests  for  Proposals  for 
hardware/software  contractors. 
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f.  Select,  define,  and  develop  human-materiel  interface  characteristics,  work  space 
layout,  work  environment,  and  effective  transfer  of  operator-maintainer  skills  for 
similar  tasks  or  similar  equipment. 

(1)  Developing  and  defining  a  work  environment  includes  detailed  analyses 
of  the  impact  the  proposed  environment  has  on  the  health  and  safety  of 
operator,  maintained  and  support  personnel. 

(2)  Analyses  of  the  work  environment  also  includes  consideration  of  the 
physical  and  cognitive  demands  on  personnel  based  on  the  operating 
tempo  of  the  assigned  unit  in  both  training  and  operational  environments. 

g.  Determine  human  performance  requirements  for  new  systems  and  match  available 
human  aptitudes  with  appropriate  training  concepts  (including  training  devices, 
simulators,  and  publications)  to  produce  required  skills 

h.  Determine  the  numbers  and  types  of  active  duty,  reserve,  and  civilian  personnel 
required  to  man  new  acquisitions  and  provide  for  subsequent  personnel  planning 
and  training.  Determine  affordability  and  supportability  of  the  manpower  and 
personnel  required. 

(1)  Provide  data  necessary  to  establish  new  military  occupational  specialties 
and  qualification  identifiers,  as  required. 

(2)  Evaluate  Coast  Guard’s  ability  to  support  personnel  and  training 
requirements  in  the  timeframes  needed  to  meet  planned  deployment  dates 
of  the  new  system. 

i.  Provide  HSI  assessments  for  Key  Decision  Point  (KDP)  reviews. 

j.  Assess  the  sensitivity  of  the  system’s  design,  cost,  and  performance  to  the 
assumptions,  estimates,  and  variations  in  human  dimensions  of  the  system. 

k.  Perform  test  and  evaluation  to  determine  that  the  design  meets  HSI  standards  in 
each  domain. 


Provide  follow-up  before  the  system  is  deployed  to  ensure  that  all  HSI  criteria 
have  been  met  in  the  system  design  and  development. 


3. 


.  The  Coast  Guard 


management  system  should  be  headed  by  the  office  responsible  for  the  HSI  Program  and  should 
include  the  following  elements:  HSI  System  Management  Plan,  HSI  Reviews,  and  HSI 
Assessments.  Exhibit  C-l  displays  these  management  elements.  The  following  paragraphs 
describe  how  each  of  the  elements  fit  into  the  management  structure. 


Coast  Guard  Management  Structure 


•  OHSIP  -  Office  Responsible  for  the 
HSI  Program 


Exhibit  C-l.  Tools  Used  to  Manage  HSI  in  Individual 
Coast  Guard  Acquisitions 


3.1  OHSIP  Management  Responsibilities.  The  OHSIP  is  responsible  for  planning  and 
executing  all  facets  of  the  HSI  Program  for  each  domain  in  each  acquisition  phase.  The 
following  are  basic  responsibilities  of  the  OHSIP  in  carrying  our  these  duties. 

a.  Writing  the  HSI  System  Management  Plan  —  See  paragraph  3.2  in  this 
section  and  Appendix  E  for  further  details. 
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b.  Developing  the  Target  Audience  Description  (TAD)  —  The  TAD 
describes  numbers  and  quality  of  personnel  force  anticipated  when  the  new 
system  is  fielded.  See  the  HSI  System  Management  Plan  Tab  E,  in 
Appendix  E,  for  further  details. 

c.  Developing  HSI  criteria,  constraints,  and  objectives  for  inclusion  into 
major  program  documents.  This  information  is  developed  from  the  Front- 
End  Analysis.  The  OHSIP  is  the  focal  point  for  system  HSI  issues  and 
criteria  during  formulation  of  the  Mission  Need  Statement,  Operational 
Requirements  Document,  Acquisition  Plan,  Program  Management  Plan, 
Test  and  Evaluation  Master  Plan,  and  Integrated  Logistic  Support  Plan. 

d.  Planning  for  and  managing  HSI  analyses,  including: 

(1)  Early  Front-End  Analysis  —  The  FEA  develops  initial  estimates 
of  manpower  and  HSI  constraints/criteria  in  all  domains  for 
inclusion  into  major  program  documents. 

(2)  Cost  Benefit  Analysis  (CBA)  —  This  is  a  systematic  and  formal 
economic  analysis  of  the  relationship  between  life-cycle  cost  and 
the  operational  effectiveness  of  each  alternative  solution  to  the 
mission  need.  While  the  PM  conducts  this  analysis,  the  MPT 
costs  are  one  of  the  prime  considerations. 

(3)  Life-Cycle  Cost  Estimate  (LCCE)  —  The  LCCE  is  developed  to 
identify  the  total  cost  to  the  Government  of  an  item  or  system  over 
its  useful  life.  MPT  costs  are  usually  major  inputs.  This  estimate 
is  first  computed  for  KDP-2  in  the  Concepts  Exploration  Phase  and 
is  updated  in  each  succeeding  phase.  By  Full  Scale  Development, 
the  life-cycle  cost  transitions  from  primarily  a  design  element  to  a 
control  element  for  the  project. 

(4)  Trade-Off  Analysis  (TOA)  —  This  analysis  is  conducted  by  the 
PM  with  inputs  from  the  Program  Sponsor  and  the  office 
responsible  for  the  HSI  Program. 

(a)  TOA  may  include  the  following: 

1  Mission  and  performance  rationale 

2  Analysis  of  system  trade-offs 

2  Selection  of  best  technical  approach  from  an 
operational  and  logistical  standpoint 


C-4 


(b)  The  TOA  identifies  critical  design  factors  and  potential  HSI 
cost  drivers. 

e.  Producing  the  HSI  Test  and  Evaluation  Program  —  HSI  test  and 
evaluation  looks  beyond  individual  domain  requirements  at  total 
operational  capability. 

(1)  The  OHSIP  forms  a  Test  Integration  Working  Group  (TTWG)  to 
coordinate  HSI  testing.  The  TIWG  is  tailored  to  match  the  size 
and  complexity  of  the  acquisition.  The  following  are 
characteristics  of  the  TIWG: 

(a)  This  working  group  is  formally  chartered  by  the  OHSIP. 

(b)  It  is  chaired  by  the  office  responsible  for  the  HSI  Program. 

(c)  Membership  in  TIWG  includes  representatives  from  the 
Program  Sponsor,  logistician,  operational  tester,  and  when 
appropriate,  the  hardware  contractor. 

(d)  The  primary  purpose  of  TIWG  is  to  direct  communications 
to  facilitate  integration  of  test  requirements  and  speed  up 
the  test  coordination  process. 

(e)  The  objective  of  TIWG  is  to  reduce  costs  by  integrating 
testing  to  the  maximum  extent,  eliminating  redundant 
testing,  and  facilitating  the  coordination  of  test  planning, 
interchange  of  test  data,  and  use  of  test  resources. 

(2)  TIWG  develops  the  HSI  portion  of  the  Test  and  Evaluation  Master 
Plan  (TEMP).  The  TEMP  is  the  basic  planning  document  that 
identifies  critical  technical  and  operational  issues  and  all  planned 
test  activities.  Human  performance  concerns  in  the  HSI  System 
Management  Plan  should  be  included  as  issues  in  the  TEMP. 
Tests  must  be  designed  so  that  accurate,  quantitative  (measurable) 
data  that  addresses  total  system  performance  can  be  gathered  and 
evaluated.  Remember  that  the  only  tests  likely  to  be  done  are 
those  included  in  the  TEMP. 

f.  Ensuring  Human  Factors  Engineering  principles  are  applied  throughout  the 
acquisition  process  and  specifically  to  the  following  areas: 

(1)  System  mission  analysis 
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(2)  Determination  of  system  functional  requirements  and  capabilities 

(3)  Allocation  of  system  functional  requirements  to 
human/hardware/software 

(4)  Development  of  system  functional  flows 

(5)  Performance  of  system  effectiveness  studies 

(6)  Test  and  mock-up  evaluations 

(7)  Dynamic  simulations 

(8)  Detail  drawing  reviews 

(9)  System  design  reviews 

(10)  System/ equipment/ component  design  and  performance  specification 
preparation  and  review 

g.  The  office  responsible  for  the  HSI  Program  has  the  option  of  establishing 
an  HSI  Joint  Working  Group  (HSUWG),  as  described  in  Appendix  L, 
when  dealing  with  an  acquisition  posing  sufficiently  complex  HSI  issues 
that  use  of  a  HSUWG  would  be  beneficial  to  properly  accommodate  all 
the  issues. 

3*2  HSI  System  Management  Plan  HSISMP.  This  is  a  planning  and  management  guide  used 
by  the  OHSIP  as  a  living  planning  and  management  record  of  all  HSI  plans,  issues,  and  actions 
taken  to  address  HSI  concerns  throughout  the  new  system’s  acquisition 

a.  The  HSISMP  is  the  first  program  management  document  in  the  entire  acquisition 
cycle.  It  is  prepared  jointly  by  the  Program  Sponsor,  Project  manager,  and  the 
office  responsible  for  the  HSI  Program,  and  it  addresses  domain-specific  issues. 
The  emphasis  in  the  HSISMP  changes  at  KDP-2,  as  described  below. 

(1)  Prior  to  Key  Decision  Point  2,  the  emphasis  is  on  influencing  design 
decisions  by  making  key  HSI  inputs  to  major  program  documents  that 
drive  and  shape  the  system  design.  Actions  include  identifying  existing 
guidance,  predecessor  systems,  data  sources,  areas  of  concern,  and 
analyses  that  will  be  required  (especially  the  very  early  analyses  that 
develop  constraints  and  performance  criteria). 

(2)  After  Key  Decision  Point  2,  the  emphasis  shifts  to  system  operational 
supportability  from  a  Manpower,  personnel,  and  Training  (MPT) 
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perspective;  resolution  of  HSI  issues;  and  integration  of  human 
performance  issues  in  other  system  documents  (e.g.,  technical  manuals 
and  operator  guides)  to  achieve  system  HSI  objectives. 


b.  The  HSISMP  documents  data  that  are  available,  or  data  that  must  be  generated, 
indicating  how,  when  ,  and  by  whom  the  data  will  be  developed.  In  addition,  the 
plan  documents  how  data  will  be  used  to  address  HSI  issues  and  concerns. 

c.  The  HSI  System  Management  Plan  provides  a  comprehensive  audit  trail  that 
documents  HSI  data  sources,  analyses,  trade-offs,  and  decisions  made  throughout 
the  acquisition  process.  The  plan  also  serves  as  documentation  of  what  was 
considered  and  why  it  was  or  was  not  used.  This  plan  provides  continuity  in  the 
HSI  acquisition  process  from  one  phase  to  the  next. 

d.  The  HSISMP  is  reviewed  and  approved  by  the  Program  Sponsor,  Project 
manager,  and  the  office  responsible  for  the  HSI  Program  prior  to  each  Key 
Decision  Point. 

e.  The  HSISMP  is  structured  in  seven  sections  as  shown  in  Appendix  E. 

3.3  HSI  Reviews  and  Assessments.  Reviews  and  assessments  are  conducted  to  determine  the 
status  and  adequacy  of  HSI  effort  and  to  present  and  unresolved  HSI  issues  or  concerns  to 
decision  makers. 

a.  Reviews  are  held  in  conjunction  with  ILS  Management  Team  reviews  of  the 
system.  They  are  done  by  the  PM  for  all  acquisitions,  and  the  results  are 
documented  in  the  HSISMP. 

b.  Assessments  are  done  prior  to  each  Key  Decision  Point  review  on  all  acquisition 
programs.  Assessments  are  conducted  jointly  by  the  Program  Sponsor  and  the 
Office  of  Acquisition.  The  results  are  documented  in  the  HSISMP  and  presented 
at  each  KDP  review. 

4.  INTERFACES  NECESSARY.  To  promote  a  smooth  functioning  and  well-integrated  HSI 
Program,  the  office  responsible  for  the  HSI  Program  must  establish  win-win  relationships  with 
the  various  organizations  that  support  HSI  in  the  acquisition  process.  See  Exhibit  C-2.  The 
following  interface  parameters  must  be  identified  and  mutually  agreed  to  by  each  organization 
involved: 

a.  Responsibilities  of  both  parties  to  the  interface  for  the  various  elements  of  HSI 
in  the  acquisition  process 

b.  Exchange  of  necessary  information,  data,  documents,  etc. 
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c.  Coordination/ communications  required  to  properly  execute  the  HSI 

Program 

The  following  paragraphs  describe  the  interface  parameters  required  between  the  office 
responsible  for  the  HSI  Program  and  the  organizations  with  specific  HSI  responsibilities  or 
having  data/other  inputs  needed  to  effectively  carry  out  the  HSI  Program  in  the  acquisition 
process. 

4.1  Interface  Between  the  Office  Responsible  for  the  HSI  Program  and  the  Program  Sponsor 
IPS)  •  This  interface  is  especially  important  since  the  PS  and  OHSIP  are  the  major  participants 
in  initiating  the  HSI  Program  for  each  acquisition  early  in  the  Project  Initiation  Phase,  well  in 
advance  of  the  PM  being  assigned. 
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a.  Responsibilities  for  HSI. 

(1)  The  PS  supports  the  HSI  Program  by: 

(a)  Including  HSI  requirements,  constraints,  and  criteria  in  major 
program  documentation,  such  as  Mission  Need  Statement  (MNS), 
Preliminary  Operational  Requirements  Document/Operational 
Requirements  Document  (PORD/ORD),  and  acquisition  objectives. 

(b)  Requiring  a  review  of  the  HSI  Program  during  all  system  program 
reviews  (e.g.,  prior  to  Key  Decision  Points). 

(c)  Funding  and  resourcing  HSI  Front-End  Analysis  (if  required). 

(2)  OHSIP  supports  the  HSI  Program  by  conducting  or  coordinating  all  HSI 
activities  in  a  materiel  acquisition,  including: 

(a)  Early  Front  End  Analysis,  development  of  Baseline  Comparison 
System  (BCS),  Initial  Estimate  of  Manpower  (IEM),  and  TAD. 

(b)  Development  of  HSI  objectives,  constraints,  performance  criteria, 
trade-offs,  risks,  cost  drivers,  and  requirements  in  all  domains. 

(c)  Coordinating  HSI  input  to  all  major  program  documentation, 
including: 

1  Major  System  Acquisition  Project  Nomination 
Memorandum 

2  MNS 

2  Acquisition  Plan  (AP) 

4  PORD/ORD 

5  Project  Management  Plan  (PMP) 

6  TEMP 

7  ILSP 

£  Request  for  Proposals  (RFPs) 
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(d)  Development  of  all  required  plans  related  to  HSI,  including: 

1  HSI  System  Management  Plan 

2  Human  Engineering  Program  Plan  (HEPP) 

2  System  Safety  Program  Plan  (SSPP) 

4  Health  Hazard  Program  Plan  (HHPP) 

5  Equipment  Facility  Report  (EPR)  Plan 

£  Training  Evaluation  Plan 

7  Coast  Guard  Training  Plan  (CGTP) 

(e)  Conducting  or  coordinating  all  required  HSI  analyses,  including: 

i.  Cost  Benefit  Analysis 

2  HFE  analyses  to  ensure  effective  and  efficient  man-machine 

interface 

2  Analysis  to  determine  System  Safety/Health  Hazards 

(SS/HH)  issues 

4  Manpower  Analysis 

5  Personnel  Analysis 

£  Training  Analysis 

7  BCS  Analysis  to  determine  IEM  and  other  domain 

parameters 

fi  Test  and  Evaluation  (T&E)  Analysis  to  test  for  and  correct 
system  HSI  problems  in  all  domains 

2  Trade-off  Analyses 

IQ  Life-Cycle  Cost  Estimate 

Exchange  of  Necessary  Information/Data/Documents/Etc.  This  category  includes 
all  types  of  shared  information  from  one  party  in  the  interface  to  the  next. 
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(1)  Inputs  from  PS  to  OHSIP 

(a)  Mission  requirements 

(b)  Technology  assessment  data 

(c)  Mission  functional  analysis  data 

(d)  System  requirements 

(e)  System  cost/effectiveness  analysis  data 

(f)  Any  MNS  updates 

(g)  Any  known  HSI  constraints,  e.g. ,  manpower  or  training  limitations 

(2)  Inputs  from  OHSIP  to  PS 

(a)  IEM 

(b)  HSI  inputs  to  MNS  and  PORD/ORD 

(c)  HSI  inputs  to  acquisition  objectives 

(d)  HSI  Program  update  at  system  program  reviews 

c.  Coordination/Communications  Required  to  Properly  Execute  the  HSI  Program. 

(1)  OHSIP  provides  PS  with  a  briefing  on  how  the  HSI  Program  works, 

coordination  required,  etc.  as  soon  as  possible  after  the  Project  Initiation 

Phase  commences. 

(2)  OHSIP  coordinates  with  PS  to  establish  the  HSUWG  and  the  HSISMP  in 

the  early  stages  of  the  Project  Initiative  Phase. 

4.2  Interface  Between  OHSIP  and  the  Project  Manger.  From  time  of  assignment,  the  PM  by 
charter  has  overall  responsibility  for  planning,  organizing,  directing,  and  controlling  the  assigned 
acquisition  project.  OHSIP  is  responsible  for  conducting  HSI  domain  processes  and  activities 
to  provide  HSI  products  and  inputs  to  the  PM  in  a  timely  manner  to  meet  the  approved 
acquisition  schedule.  Since  the  PM  is  not  assigned  until  the  Concepts  Exploration  Phase,  OHSIP 
will  have  started  and  completed  a  significant  amount  of  Front-End  Analyses  and  HSI  planning 
when  the  PM  is  assigned.  One  of  the  responsibilities  of  OHSIP,  as  soon  as  convenient  after  the 
PM  reports,  is  to  brief  the  new  PM  on  all  HSI  activities  underway,  completed,  and  planned  for 
the  future. 
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The  HSI  Program  will  provide  the  acquisition  process  with  domain  experts  who  have  not  been 
available  in  the  past  and  who  will  commence  developing  domain  processes  in  the  Project 
Initiation  Phase,  much  earlier  than  they  occurred  in  the  past.  A  substantial  amount  of  planning 
and  analyses  that  the  PM  has  previously  been  required  to  do  should  already  be  completed  when 
the  PM  reports.  The  PM  should  arrive  with  a  process  well  underway  to  influence  system  design 
in  all  five  HSI  domains,  while  systematically  developing  MPT  requirements  in  a  timely  fashion. 
The  HSI  Program  should  reduce  the  PM’s  workload  while  greatly  improving  both  systems 
design  and  the  process  of  developing  life-cycle  support  requirements. 

a.  Responsibilities  for  HSI. 

(1)  The  PM  supports  the  HSI  Program  by: 

(a)  Including  HSI  objectives,  constraints,  performance  criteria,  trade¬ 
offs,  risks,  cost  drivers,  and  requirements  in  major  program 
documentation,  including  PMP,  AP,  TEMP,  and  ILSP 

(b)  Including  HSI  status  and  issues  as  part  of  all  program  reviews 

(c)  Providing  adequate  funding  for  any  remaining  HSI  Front-End 
Analyses.  (Note:  Since  the  PM  is  not  assigned  to  the  project  until 
the  Concepts  Exploration  Phase,  the  OHSIP  should  be  separately 
funded  (or  appropriately  manned  with  qualified  analysts)  to 
conduct  required  Front-End  Analyses.  These  critical  analyses 
must  be  mostly  completed  in  the  Project  Initiation  and 
Requirements  Definition  Phases  to  have  any  impact  on  system 
design.) 

(d)  Requiring  MPT  inputs  for  each  design  alternative;  presenting  the 
Coast  Guard  decision  authority  with  the  balance  between 
acquisition  and  ownership  costs  for  each  design  alternative 

(e)  Assisting  the  OHSIP  where  possible  to  ensure  (1)  that  the  HFE  and 
SS/HH  are  included  in  the  system  design,  and  (2)  that  all  HSI 
plans  are  properly  executed,  the  results  are  included  in  applicable 
documentation, a  nd  all  recommended  HSI  inputs  are  considered  or 
made  available  to  appropriate  Coast  Guard  decision  authorities 

(f)  Assisting  the  OHSIp  where  possible  to  ensure  that  all  HSI  domains 
are  properly  tested  and  that  follow-up  occurs  to  ensure  al  HSI 
criteria  are  met  in  the  deployed  system 

(g)  Including  HSI  requirements  in  the  Circular  of  Requirements/RFP 
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(h)  Using  HSI  as  one  of  major  source  selection  criteria 

(2)  The  OHSIP  supports  the  HSI  Program  by:  Refer  to  OHSIP 
responsibilities  under  paragraph  4.1.a.(2). 

b.  Exchange  of  Necessary  Information/Data/Documents/etc. 

(1)  Inputs  from  PM  to  OHSIP  —  There  should  be  mutually  agreed  inputs 
determined  on  a  case  basis  as  a  working  relationship  is  established  with 
each  new  PM. 

(2)  Inputs  from  OHSIP  to  PM 

(a)  Program  guidance  and  constraints  known  to  joint  working  group 
members  that  impact  HSI  domains 

(b)  Data  from  members  with  institutional  data  bases,  such  as 
manpower  planning  data,  and  personnel  data  describing 
characteristics  for  use  in  the  TAD  and  the  amount/kind  of  training 
currently  received  by  ratings/pay  grades  of  interest,  etc. 

(c)  Review  HSI  plans,  completed  analyses,  and  other  HSI 
documentation  as  requested 

(2)  Inputs  from  OHSIP  to  HSUWG 

(a)  HSI  inputs  to  major  program  documentation,  including  PMP,  AP, 
TEMP,  and  ILSP 

(b)  HSI  inputs  for  program  reviews 

(c)  MPT  inputs  for  each  design  alternative  and  Life-Cycle  Cost 
Estimates 

(d)  HSI  inputs  as  required  for  all  domains,  including  inputs  for  trade¬ 
off  analyses,  risk  assessments,  feasibility  studies,  configuration 
management,  testing,  RFP  development,  and  Operational  Logistic 
Support  Plans  (OLSPs) 

(e)  HSI  training  as  required  for  PM  matrix  organization 
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c. 


Coordination/Communications  Required. 


(1)  As  soon  as  convenient  after  the  PM  is  assigned,  OHSIP  should  brief  the 

new  PM  on  HSI  activities  in  the  first  two  phases,  as  well  as  planned 

follow-on  activities,  including: 

(a)  HSI  constraints,  objectives,  criteria,  and  requirements. 

(b)  HSI  inputs  to  Major  System  Acquisition  Project  Nomination 
Memorandum  (i.e.,  IEM),  acquisition  objectives/strategy,  and 
PORD/ORD 

(c)  The  BCS  chosen  and  information  derived  from  it 

(d)  Any  Front-End  Analyses  that  remains  to  be  completed 

(e)  Any  plans  or  issues  still  being  worked,  including  any  requiring  PM 
support  or  assistance 

(2)  There  should  be  periodic  discussions  between  the  OHSIP  and  PM  on  the 

status  of  HSI  issues/concems  of  mutual  interest. 

4.3  Interface  Between  OHSIP  and  the  Manpower  Proponent  in  the  Office  of  the  Chief  of  Staff. 
G-CCS  is  responsible  for  management  of  current  year  and  out  year  manpower  requirements,  and 
for  approving  all  military /civilian  billets/positions  in  the  Coast  Guard.  In  meeting  these 
responsibilities,  the  Office  of  the  Chief  of  Staff  has  developed  manpower  expertise  and 
billet/position  data  that  OHSIP  needs  to  properly  execute  the  HSI  Program.  G-CCS,  for 
example,  is  the  Coast  Guard  expert  on  the  affordability  of  manpower  and  on  the  appropriate 
military/civilian  manpower  mix  needed  to  meet  the  requirements  of  new  acquisitions. 

a.  Responsibilities  for  HSI. 

(1)  The  Manpower  Proponent  supports  the  HSI  Program  by: 

(a)  Providing  an  officer/enlisted/civilian  Manpower  Planning  System 
for  use  in  evaluating  manpower  affordability  of  the  new  system 
based  on  known  or  anticipated  end-strength  ceilings  and  other 
known  manpower  requirements  in  the  years  the  new  system  is 
expected  to  be  delivered 

(b)  Working  with  OHSIP  to  assess  manpower  affordability  for  the  new 
acquisition 
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(c)  Advising  OHSIP  on  the  number  and  quality  of  billets  needed  to 
support  the  General  Detail  Account  for  new  acquisitions,  based  on 
the  number  and  quality  of  billets  required  for  the  new  system 

(d)  Providing  assistance  as  necessary  to  meet  the  manpower 
requirements  of  the  HSI  Program 

(2)  OHSIP  Supports  the  HSI  Program  By:  Refer  to  OHSIP  responsibilities 
under  paragraph  4.1.a.(2). 

b.  Exchange  of  Necessary  Information/Data/Documents/etc. 

(1)  Inputs  from  the  Office  of  the  Chief  of  Staff  to  OHSIP 

(a)  Data  as  required  from  Manpower  Planning  and  Tracking  Systems, 
plus  any  additional  information  that  may  be  useful  in  system  design 

(b)  Manpower  expertise  for  advice  on  plans,  concepts,  analyses, 
testing,  etc. 

(c)  Assistance  in  determining  system  manpower  affordability  and  other 
manpower  issues 

(2)  Inputs  from  OHSIP  to  the  Office  of  the  Chief  of  Staff— OHSIP  will 
periodically  discuss  HSI  manpower  requirements  with  representatives  of 
the  Office  of  the  Chief  of  Staff  to  determine  if  inputs  are  required. 

c.  Coordination/Communications  Required.  There  should  be  periodic  discussions 
between  managers  in  the  Office  of  the  Chief  of  Staff  and  OHSIP  on  the  status  of 
HSI  matters  of  mutual  interest,  and  to  provide  feedback  to  both  parties  on  how 
the  HSI  process  is  working. 

(1)  As  soon  as  convenient  after  the  PM  is  assigned,  OHSIP  should  brief  the 
new  PM  on  HSI  activities  in  the  first  two  phases,  as  well  as  planned 
follow-on  activities,  including: 

4.4  Interface  Between  OHSIP  and  the  Manpower  Proponent  in  the  Office  of  Personnel  and 
Training.  The  Office  of  Personnel  and  Training  is  responsible  for  all  aspects  of  Coast  Guard 
personnel  management.  In  meeting  these  responsibilities  for  all  aspects  of  Coast  Guard 
personnel  management.  In  meeting  these  responsibilities,  the  Office  of  P  has  developed 
personnel  expertise  and  data  that  are  required  by  OHSIP  in  executing  the  HSI  Program  in  system 
acquisitions.  For  example,  the  Office  of  P  is  the  Coast  Guard  expert  on  how  many  of  what 
kinds  of  people  the  Coast  Guard  expects  to  have  and  to  need  in  the  future,  and  whether  the 
personnel  requirements  of  the  new  acquisition  can  be  adequately  supported  in  the  timeframe  required. 
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a.  Responsibilities  for  HSI. 


(1)  The  Manpower  Proponent  supports  the  HSI  Program  by: 

(a)  Providing  an  officer/enlisted/civilian  Personnel  Tracking  System 
and  other  data  bases  for  use  in  developing  the  TAD  and 
determining  the  training  provided  to  rating  and  skill  specialties  of 
interest 

(b)  Providing  occupational  standards  relating  specific  skill  levels  to 
each  enlisted  rating  and  pay  grades  and  providing  similar 
information  for  civilian  career  fields/pay  plans 

(c)  Working  with  OHSIP  to  assess  manpower  affordability  and 
whether  the  personnel  system  is  able  to  support  the  new  system 
with  the  numbers  of  qualified  and  trained  personnel  needed  and  in 
the  timeframe  required 

(2)  OHSIP  supports  the  HSI  Program  by:  Refer  to  OHSIP  responsibilities 

under  paragraph  4. 1  .a. (2). 

b.  Exchange  of  Necessary  Information/Data/Documents/etc. 

(1)  Inputs  from  the  Office  of  P  to  OHSIP 

(a)  Data  as  required  Personnel  and  Tracking  Systems,  plus  any 
additional  information  that  may  be  useful  in  system  design 

(b)  Occupational  standards  as  required 

(c)  Personnel  expertise  to  advise  on  plans,  concepts,  analyses,  testing, 
etc. 

(d)  Assistance  in  determining  system  personnel  supportability 

(2)  Inputs  from  OHSIP  to  the  Office  of  P  —  OHSIP  will  periodically  discuss 

Personnel  HSI  requirements  with  Office  of  P  representatives  to  determine 

if  inputs  are  required. 

C-  Coordination/Communications  Required.  There  should  be  periodic  discussions 
between  Managers  in  the  Office  of  P  and  OHSIP  on  the  status  of  HSI  matters  of 
mutual  interest,  and  to  provide  feedback  to  both  parties  on  how  the  HSI  process 
is  working. 
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4.5  Interface  Between  OHSIP  and  the  Personnel  Proponent  in  the  Office  of  Personnel  and 
Training.  As  the  Coast  Guard  institutional  representative  for  the  training  domain,  the  Office  of 
P  is  the  expert  on  Coast  Guard  training  capabilities  and  limitations.  The  Office  of  P  has  both 
training  expertise  and  training  data  on  courses  and  training  capacity  that  are  required  by  OHSIP 
to  adequately  determine  the  training  required  and  develop  the  Coast  Guard  Training  Plan  for  new 
acquisitions. 


a.  Responsibilities  for  HSI. 

(1)  The  Personnel  Proponent  supports  the  HSI  Program  by: 

(a)  Providing  details  on  existing  training  courses  and  training  facilities 
in  the  Coast  Guard,  including  courses  available  from  the  Navy  and 
other  known  sources 

(b)  Working  with  the  OHSIP  to  develop  the  most  cost  effective  and 
workable  Coast  Guard  Training  Plan 

(2)  OHSIP  supports  the  HSI  Program  by:  Refer  to  OHSIP  responsibilities 
under  paragraph  4.1.a.(2). 

b.  Exchange  of  Necessary  Information/Data/Documents/Etc. 

(1)  Inputs  from  the  Office  of  P  to  OHSIP 

(a)  Data  as  necessary  on  existing  Coast  Guard  training  courses  and 
training  facilities 

(b)  Training  expertise  for  advice  on  plans,  training  concepts,  analyses, 
testing,  and  the  CGTP  for  the  new  system 

(2)  Inputs  from  OHSIP  to  Office  of  P  —  OHSIP  will  periodically  discuss 
training  requirements  with  the  Office  of  P  representatives  to  determine  if 
inputs  are  required 

c.  Coordination/Communications  Required.  There  should  be  periodic  discussions 
between  Training  Managers  in  the  Office  of  P  and  OHSIP  on  the  status  of 
training  matters  of  mutual  interest,  and  to  provide  feedback  to  both  parties  on 
how  the  HSI  process  is  working. 

4.6  Interface  Between  OHSIP  and  the  SS/HH  Proponent  in  the  Office  of  Health  and  Safety. 
The  Office  of  Health  and  Safety  has  delegated  the  authority  to  satisfy  SS/HH  domain 
requirements  in  system  acquisitions  to  the  Office  of  Acquisition.  Even  so,  the  Office  of  K  has 
health  and  safety  expertise  and,  perhaps,  data  that  is  useful  to  OHSIP  in  carrying  out  SS/HH 
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domain  responsibilities  in  individual  acquisitions.  The  Office  of  A  should  have  useful  records 
of  past  acquisitions,  including  SS/HH  lesson  learned. 

a.  Responsibilities  for  HSI. 

(1)  The  SS/HH  Proponent  supports  the  HSI  Program  by: 

(a)  Providing  SS/HH  lesson  learned  and  any  other  data  support  that 
could  be  applied  to  the  design  of  new  acquisitions 

(b)  Providing  SS/HH  expertise  to  help  solve  safety  and  health  hazard 
issues  in  system  design 

(2)  OHSIP  supports  the  HSI  Program  by:  Refer  to  OHSIP  responsibilities 
under  paragraph  4.1.a.(2). 

b.  Exchange  of  Necessary  Information/Data/Documents/etc. 

(1)  Inputs  from  the  Office  of  K  to  OHSIP 

(a)  Any  available  SS/HH  data  appropriate  to  system  design 

(b)  Advise  in  developing  SS/HH  Plans  and  in  problem  solutions 

(2)  Inputs  from  OHSIP  to  the  Office  of  K  —  OHSIP  will  periodically  discuss 
SS/HH  requirements  with  Office  of  K  representatives  and  determine  if 
inputs  are  required. 

c.  Coordination/Communications  Required.  There  should  be  periodic  discussions 
between  safety  and  health  hazard  managers  in  the  Office  of  K  and  OHSIP  on  the 
status  of  SS/HH  matters  of  mutual  interest,  and  to  provide  feedback  to  both 
parties  on  how  the  HSI  process  is  working. 

4.7  Interface  Between  OHSIP  and  the  Human  Factors  Engineering  Proponent.  Human  Factors 
Engineers  are  trained  in  human  psychological,  social,  physical,  and  biological  characteristics  and 
limitations.  This  body  of  knowledge  is  applied  to  the  design,  operation,  and  use  of  materiel 
systems  to  optimize  human  performance,  health,  safety,  and  habitability. 

In  applying  human  factors  during  the  design  of  a  new  acquisition,  the  engineer  identifies  all  the 
interactions  that  humans  require  with  machines  in  operating,  maintaining,  and  otherwise 
supporting  the  new  system.  This  is  accomplished  through  functional  allocation  and  the  analysis 
of  each  human  task  to  be  performed.  The  HFE  subsequently  ensures  that  each  man-machine- 
interface  (MMI)  is  designed  to  maximize  system  performance.  The  Human  Factors  Engineering 
Domain  makes  the  greatest  contribution  of  all  the  domains  to  hardware,  software,  and  procedural 
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design,  specifically  to  ensure  proper  functioning  of  the  equipment  levels,  etc.)  that  the  Coast 
Guard  anticipates  having  available  to  support  the  new  system  when  fielded. 

In  carrying  out  these  responsibilities,  the  HFE  assigned  to  the  OHSIP  will  need  to  interface 
periodically  with  other  Coast  Guard  Human  Factors  specialist  to  exchange  ideas  and  information 
pertinent  to  HFE  in  the  Coast  guard.  In  addition,  the  engineer  will  occasionally  need  other 
inputs  and  perspectives  regarding  specific  human  factors  issues  that  arise  during  the  acquisition 
process. 

a.  Responsibilities  for  HSI. 

(1)  The  Human  Factors  Engineering  Proponent  supports  the  HSI  Program  by: 

(a)  Assisting  as  requested  in  the  review  of  HFE  plans,  issues, 
analyses,  and  tests  involved  in  individual  Coast  Guard  acquisitions 

(b)  Providing  data,  studies,  and  other  applicable  HFE  information,  as 
requested 

(2)  OHSIP  supports  the  HSI  Program  by:  Refer  to  OHSIP  responsibilities 
under  paragraph  4.1.a.(2). 

b.  Exchange  of  Necessary  Information/Data/Documents/etc. 

(1)  Inputs  from  the  Human  Factors  Engineering  Proponent  to  OHSIP  —  Any 
information,  data,  or  advice  that  furthers  OHSIP  efforts  to  meet  HFE 
requirements  in  the  Coast  Guard  acquisition  process 

(2)  Inputs  from  OHSIP  to  HFE  Proponent 

(a)  Update  on  the  status  of  individual  acquisitions  as  mutually  agreed 

(b)  Other  inputs  appropriate  to  keeping  the  HFE  Proponent  informed 
on  areas  of  mutual  interest 

c.  Cnordination/Communications  Required.  There  should  be  periodic  discussions 
between  OHSIP  and  the  HFE  Proponent  on  the  status  of  HSI  mattes  of  mutual 
interest,  and  to  provide  feedback  to  both  parties  on  how  the  HSI  process  is 
working. 

4.8  Interface  Between  OHSIP  and  the  ILS  Manager.  While  the  ILS  and  HSI  Programs  both 
require  access  to  some  of  the  same  data  in  executing  their  responsibilities,  the  objectives  of  the 
two  programs  are  fundamentally  different.  ILS  is  chartered  to  determine  and  document 
supportability  of  acquisition  systems;  HSI’s  focus  is  on  performance  and  operability  in  those 
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same  systems.  HSI  has  a  more  systems  engineering  orientation  and  an  overriding  concern  for 
impacting  system  design.  Rather  than  conflicting,  ILS  Manager  will  benefit  from  a  substantial 
amount  of  research  and  analysis  conducted  by  the  OHSIP,  including  the  IEM,  TAD,  and  most 
(perhaps  all)  of  the  FEA. 


The  ILS  Manager  has  traditionally  been  required  to  start  developing  the  ILS  Program 
requirements  after  reporting  to  the  project  near  the  middle  of  the  Concepts  Exploration  Phase. 
With  the  HSI  Program  in  place,  the  ILS  Manager  will  benefit  from  a  substantial  amount  of 
research  and  analysis  conducted  by  the  OHSIP,  including  the  IEM,  TAD,  and  most  (perhaps  all) 
of  the  FEA. 


OHSIP  will  have  performed  the  initial  Front-End  Analysis  when  the  ILS  Manager  reports  to  the 
Project,  and  can  start  with  that  information  as  a  hand-off  from  OHSIP.  Many  ILS  tasks  will 
complement  the  HSI  analysis  in  such  areas  as  design  alternatives,  while  other  tasks  are  almost 
completely  maintenance  related  and  are  normally  done  entirely  by  the  ILS  Manager.  Included 
are  such  items  as  supportability-related  factors  for  repair  parts  cost,  sparing  methodology,  and 
tools  and  test  equipment  that  are  not  a  part  of  the  MAPT1DES  Methodology. 

The  primary  focus  of  the  ILS  Manager  in  system  acquisitions  is  on  spares,  tools  and  test 
equipment,  technical  manuals,  maintenance  training  materials,  maintenance  manpower,  and 
training  course  development  for  maintained.  The  OHSIP  is  also  interested  in  providing  HFE 
inputs  to  such  areas  as  cautions/wamings  in  technical  publications  (where  safety  and  health 
hazards  information  is  required),  as  well  as  training  material  requirements,  and  what  training 
courses  are  needed.  With  the  proper  interface,  the  ILS  Manager  should  benefit  from  OHSIP’s 
early  analyses,  and  the  requirements  of  both  parties  should  be  met  without  duplication  of  effort. 

a.  Responsibilities  for  HSI 

(1)  The  ILS  Manager  supports  the  HSI  Program  by: 

(a)  Further  refining  and  documenting  maintenance  manpower 
requirements 

(b)  Ensuring  that  HFE  procedural  development  is  included  in  system 
technical  publications 

(c)  Ensuring  that  system  safety  and  health  hazard  requirements  are 
included  in  cautions  and  warnings  at  appropriate  locations  in 
operator  and  maintainer  technical  manuals 

(d)  Refining  and  documenting  training  material  requirements 

(2)  The  OHSIP  supports  the  HSI  Program  by:  Refer  to  OHSIP 

responsibilities  under  paragraph  4.1. a. (2). 
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(1)  Inputs  from  the  ILS  Manager  to  OHSIP 


(a)  Any  additional  information  that  changes  the  number  of  quality  of 
maintenance  manpower  from  OHSIP  estimates 

(b)  Any  additional  information  that  changes  the  maintenance  training 
materials  from  OHSIP  estimates 

(c)  Information  that  causes  any  OHSIP  MPT  estimates  to  be  reviewed 
or  changed 

(2)  Inputs  from  OHSIP  to  ILS  Manager 

(a)  Any  HFE  inputs  that  should  be  reflected  in  system  operator  or 
maintainer  technical  publications 

(b)  All  MPT  estimates  at  the  time  the  ILS  Manager  is  assigned 
c.  Coordination/Communications  Required. 

(1)  OHSIP  will  brief  the  ILS  Manger  on  all  analyses  and  MPT 
estimates  derived  up  to  the  time  the  ILS  Manager  is  assigned  and 
on  planned  activity  in  follow-on  phases. 

(2)  Both  the  OHSIP  and  the  ILS  Manager  should  coordinate  their 
activities  and  communicate  their  findings  of  interest  to  both  parties 
throughout  the  acquisition  phases. 

(3)  There  should  be  periodic  discussions  between  the  ILS  Manager  and 
OHSIP  on  the  status  of  MPT  matters  of  mutual  interest  and  to 
provide  feedback  to  both  parties  on  how  the  HSI  process  and  the 
ILS  program  are  dovetailing  together. 
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SECTION  D 

HSI  PROGRAM  PROCESSES 


This  section  covers  the  more  critical  aspects  of  executing  an  effective  HSI  Program.  The  section 
begins  with  a  discussion  of  the  data  and  data  bases  the  OHSIP  needs  to  influence  system  design 
and  determine  MPT  requirements.  Next  is  a  description  of  the  Front-End  Analysis  and  a 
discussion  of  the  critical  nature  of  this  early  analysis  on  the  HSI  Program’s  ability  to  influence 
system  design.  That  is  followed  by  a  description  of  Request  for  Proposal  (RFP)  requirements 
and  a  discussion  of  cost  determination  in  the  HSI  Program.  The  section  culminates  with  a 
description  of  the  specific  domain  processes  recommended  for  the  Coast  Guard  HSI  Program. 

1.  DATA  AND  DATA  BASES  REQUIRED.  Success  of  the  HSI  Program  depends  on  the 
OHSIP’s  ability  to  identify  information  needed,  collect  and  develop  that  information,  and  use 
the  results  to  influence  the  system  design.  This  paragraph  will  discuss  the  five  primary 
categories  of  information  and  the  two  types  of  data  systems  required. 

a.  Categories  of  HSI  Information  —  The  following  five  main  categories  of  HSI 
information  are  discussed  including  data  sources. 

(1)  Deficiency  Information/Performance  Requirements  —  What  people  tasks 
are  difficult  to  train  or  perform?  What  man-machine  interface  problems 
have  been  identified  in  predecessor  or  similar  systems? 

(a)  Sources  of  this  type  of  information  include  Operational 
Requirements  Documents  (assuming  the  requirements  system  is 
concepts-based). 

(b)  Types  of  information  available  include  those  that: 

1  Identify  deficiencies 

2  Identify  overall  performance  requirements 

3  Promulgate  objectives 

(2)  Program  Guidance  —  What  decisions  have  been  made  that  impact  system 
design  (capabilities)  or  impose  constraints  or  limitations  on  available 
resources  (e.g.,  manpower,  personnel,  training  base,  or  funding 
resources)?  Sources  of  this  type  of  information  include  the  following: 

(a)  Coast  Guard/Department  of  Transportation  (DoT)  Program 
Guidance  including  Coast  Guard  resource  constraints  on  training 
time,  dollars,  personnel,  and  manpower. 
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(b)  The  Office  of  Acquisition  also  promulgates  guidance  that  falls  into 
this  category. 

(3)  Lessons  Learned  —  What  are  the  human  performance  deficiencies  of  the 
current  system?  What  residual  hazards  have  not  been  eliminated  from  the 
current  or  similar  systems?  Sources  of  this  type  of  information  include 
the  following: 

(a)  Lessons-leamed  data  bases  in  each  domain,  including: 

1  Safety  lessons 

2  Logistics  lessons,  including  MPT 

2  Health  lessons 

4  High  drivers 

2  Human  Factors  Engineering  lessons 

(b)  Records  of  previous  acquisitions  are  a  primary  source  of  this 
category  of  information. 

(4)  Prediction  —  Have  the  abilities  and  limitations  of  future  Coast  Guard 
personnel  been  considered  when  computing  the  total  system  performance 
requirements  of  the  new  system?  Have  all  the  ownership  costs  been 
included  when  computing  total  life-cycle  cost  of  the  system?  Sources  of 
this  type  of  information  include: 

(a)  Target  Audience  Description  (TAD) 

(b)  Front-End  Analyses 

(c)  Other  Predictions  of  Future  Limitations  and  Constraints 

(5)  HSI  Assessment  —  What  unresolved  HSI  issues  need  to  be  addressed? 
What  is  the  status  of  key  source  documents  and  analyses?  Sources  of  this 
type  of  information  include  assessments  done  prior  to  each  Key  Decision 
Point  to  resolve: 

(a)  Unresolved  Issues 

(b)  Status  of  Key  Analyses 
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b.  Data  System  Requirements  —  Two  types  of  data  systems  are  required  to  support 
the  HSI  Program  in  the  acquisition  process:  A  data  system  to  track  and  document 
issues,  analyses,  actions  taken,  and  lessons  learned  in  each  domain  for  each 
acquisition  project  (i.e.,  this  is  one  data  system  with  a  module  for  each  domain); 
and  institutional  data  systems  maintained  by  and  for  the  primary  use  of 
organizations  responsible  for  that  functional  area. 

(1)  The  following  institutional  data  systems  are  needed: 

(a)  Manpower  Planning  System  —  This  system  projects  manpower 
(billet)  requirements  for  each  year  over  the  next  5  years 
(minimum). 

1  The  system  should  include  three  billet  modules:  officer, 
enlisted,  and  civilian.  Officer  and  enlisted  modules  should 
include  both  active  duty  and  reserves. 

2  The  military  billets/civilian  positions  in  each  module  should 
include:  billet/position  title,  occupational  specialty,  pay 
grade,  and  special  skill  requirements. 

2  The  Manpower  Planning  System  will  be  used  by  the 
acquisition  process  to  answer  questions  such  as  the 
following:  Is  the  Coast  Guard  manpower  required  for  this 
new  system  affordable?  Does  the  Coast  Guard  expect  to 
have  die  appropriate  occupational  specialties  required  for 
this  system  or  must  a  new  rating  be  developed? 

(b)  Personnel  Planning  System  —  This  system  projects  personnel 
expected  to  be  in  the  Coast  Guard  for  each  year  over  the  next  5 
years  (minimum).  The  Target  Audience  Description  is  partially 
derived  from  the  Personnel  Planning  System. 

1  This  system  should  include  three  modules:  officers, 
enlisted,  and  civilian.  Officer  and  enlisted  modules  should 
include  both  active  duty  and  reserves. 

2  Officer  and  enlisted  modules  should  include  the  personnel 
expected  in  the  Coast  Guard  each  year.  Each  individual 
should  have  a  military  occupation,  pay  grade,  special  skills 
identifiers,  training  received,  Armed  Forces  Qualification 
Test  (AFQT)  or  other  mental  group  scores,  and  Armed 
Services  Vocational  Aptitude  Battery  (ASVAB)  or  other 
aptitude  scores. 
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2  This  system  will  be  used  to  answer  such  questions  as: 
What  range  of  aptitude  scores  are  appropriate  for  personnel 
in  the  new  system?  What  occupational  specialty  is  most 
appropriate  for  the  new  acquisition? 

(c)  Training  Data  System  —  This  data  system  provides  existing 
training  course  information,  including  Coast  Guard  and  applicable 
Navy  schools,  home  study,  and  other  courses  available  to  the 
Coast  Guard. 

1  The  system  should  provide  the  following  information: 
Description  of  each  course,  length,  location,  and  entrance 
criteria  (e.g.,  AFQT  scores,  experience,  and  occupational 
specialty). 

2  Data  from  this  system  will  answer  questions  such  as:  Does 
the  Coast  Guard  have  a  training  course  already  available  to 
support  this  new  system  or  must  a  new  course  be 
developed? 

(d)  Human  Factors  Engineering  Data  System  —  This  data  system 
should  provide  information  that  enables  the  identification  of  system 
elements  to  be  targeted  for  Human  Factors  Engineering  during  the 
system  development  cycle. 

1  The  system  should  provide  the  following  information: 
Historical  human  factors  data  that  consists  of  design 
solutions  that  were  addressed  and  ameliorated  by  HFE  in 
previous  design  and  similar  acquisition  efforts. 

2  Data  from  this  system  should  answer  questions  such  as: 
Has  the  Coast  Guard  experienced  problems  in  similar 
equipment  in  the  past  that  can  be  solved  by  proper  HFE 
design  of  the  new  system?  Are  there  particular  HFE 
techniques  that  have  worked  better  for  equipment  such  as 
that  included  in  the  new  acquisition? 

(e)  System  Safety/Health  Hazards  Data  System  —  This  data  system 
provides  historical  safety  data  that  includes  lessons  learned  from 
previous  design  and  similar  acquisition  efforts. 

I  The  system  should  provide  the  following  information: 
Design  solutions  that  were  addressed  and  ameliorated  by 
System  Safety  Engineering  in  previous  design  and  similar 
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acquisition  efforts.  The  system  also  should  classify  hazards 
encountered  and  ameliorated  during  previous  system 
design,  operation,  and  support. 

2  Data  from  this  system  should  answer  questions  similar  to 
the  following:  Has  the  Coast  Guard  experienced  problems 
in  similar  equipment  in  the  past  that  can  be  solved  by 
incorporation  of  SS/HH  considerations  into  the  design  of 
the  new  system?  Are  there  particular  SS/HH  procedures  or 
techniques  that  have  worked  best  for  Coast  Guard  in  the 
past  and,  therefore,  should  be  considered  in  the  new 
acquisition? 

(2)  A  data  system  is  needed  to  track  individual  acquisition  projects. 

(a)  This  requires  a  data  system  with  modules  for  each  of  the  HSI 
domains,  an  HSI  Program  module  for  the  HSI  System 
Management  Plan  (HSISMP),  and  other  documentation  not  related 
to  a  single  domain. 

1  This  system  tracks  the  various  iterative  processes 
encountered  during  a  system  acquisition. 

2  The  result  is  retained  as  a  historical  record  for  use  as  a 
Baseline  Comparison  System  and  lessons  learned  in  future 
acquisitions. 

(b)  The  following  modules  are  required  by  the  domains  indicated. 
Recorded  data  developed  by  each  domain  is  required  as  inputs  to 
program  documentation  in  each  acquisition  phase. 

1  Human  Factors  Engineering  Data  Base  —  Records  all  HFE 
plans,  analyses,  assessments,  interface  problems  and 
solutions,  lessons  learned,  and  other  HFE  activities  as 
necessary. 

2  System  Safety/Health  Hazards  (SS/HH)  Data  Base  — 
Records  all  SS/HH  activity  including  plans,  analyses, 
assessments,  problem  areas  and  solutions,  lessons  learned, 
etc. 

2  Manpower  Data  Base  —  Includes  data  from  the  Manpower 
Planning  System  applicable  to  this  acquisition,  manpower 
plans,  analysis,  Initial  Estimate  of  Manpower, 
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Manpower/Personnel  and  Training  Integration  in  the 
Design  of  Systems  (MAPTIDES)  Methodology  applicable 
to  each  phase  of  this  acquisition  (described  later  in  this 
section),  final  estimates  of  manpower,  lessons  learned,  and 
other  manpower  data  as  required. 

4  Personnel  Data  Base  —  Includes  data  from  the  Personnel 
Planning  System  applicable  to  this  acquisition,  personnel 
plans,  analysis,  skill  level,  mental  group  trade-offs,  final 
determination  of  supportability,  lessons  learned,  and  other 
personnel  data  as  necessary. 

1  Training  Data  Base  —  Records  training  plans,  analysis, 
trade-offs,  training  inputs  for  each  design  alternative, 
training  costs  for  total  life-cycle  cost  estimates,  lessons 
learned,  and  other  training  data  as  required. 

f>  HSI  Program  Data  Base  —  Includes  all  HSI  plans,  issues, 
activities,  and  documentation  not  directly  related  to 
developing  individual  domain  inputs.  The  following  are 
examples  of  this  type  of  data: 


g  HSISMP  and  updates 

k  Program  document  inputs  are  normally  collected 

from  all  domains  and  consolidated  into  one  HSI 
input 

£  Hardware/software  contractor  inputs  to  RFPs 

d  Life-cycle  cost  estimates 


2-  FRONT-END  ANALYSIS  (TEAL  The  FEA  is  the  most  critical  step  required  to  develop 
the  information  needed  for  HSI  to  influence  system  design  in  an  individual  acquisition.  The 
FEA  determines  HSI  constraints,  performance  criteria,  objectives,  trade-offs,  risks,  cost  drivers, 
and  other  inputs  required  for  program  documentation,  and  it  also  includes  strategy  and  criteria 
for  integrating  HSI  into  design  specifications.  Without  this  critical  information  on  the  front-end 
of  the  process  when  program  documents  are  being  developed,  HSI  cannot  influence  system 
design. 


a.  Mission  and  Support  System  Definition  tasks  form  the  nucleus  of  FEA  (other 
analyses  may  be  required  by  OHSIP).  The  tasks  include  the  following: 
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(1)  Task  1.  Use  Study  —  Identifies  and  documents  pertinent  supportability 
factors  of  the  proposed  system,  including  the  following: 

(a)  Deployment  scenarios 

(b)  Mission  frequency  and  duration 

(c)  Service  life 

(d)  Operational  environment 

(2)  Task  2.  Mission  Hardware,  Software,  and  Support  System 
Standardization  —  This  task  defines  design  constraints  of  the  proposed 
system  based  upon  existing  and  planned  logistic  support  resources  (i.e., 
use  as  much  existing  support  as  possible  before  acquiring  something 
new).  It  also  provides  supportability  input  to  mission  hardware  and 
software  standardization  efforts. 

(a)  The  results  of  this  task  are  used  as  inputs  to  Tasks  1  and  4. 

(b)  It  also  includes  supportability  constraints,  supportability 

characteristics,  recommended  approaches,  and  risks  (e.g. ,  risks 
in  terms  of  cost,  personnel,  and  technical  risk)  for  each  HSI 
domain. 

(3)  Task  3.  Comparative  Analysis  —  Develops  a  Baseline  Comparison 
System  (BCS)  representing  the  characteristics  of  the  proposed 
equipment  for: 

(a)  Projecting  supportability-related  factors  and  identifying  targets 
for  improvement.  This  is  based  on  lessons  learned  in  all  HSI 
domains  from  previous  systems. 

(b)  Determining  supportability,  cost,  and  readiness  drivers  for  the 
proposed  system. 

(c)  Documenting  risks  associated  with  using  comparative  data. 

(d)  Developing  supportability  factors  to  be  incorporated  into 
operational  requirements  and  as  input  to  Tasks  4  and  5. 

(e)  Determining  Initial  Estimate  of  Manpower  (IEM)  and 
refinements  in  later  phases. 
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(4)  Task  4.  Technological  Opportunities  —  Identifies  technological 
advancements  and  state-of-the-art  design  approaches  that  offer 
opportunities  for  achieving  improvements  in  the  new  system. 

(a)  Qualitative  support  characteristics  of  alternative  design  and 
operational  concepts  (e.g.,  modular  replacements  for 
organizational-level  maintenance  concept). 

(b)  Support  and  support-related  design  objectives,  goals  and 
thresholds. 

(c)  Constraints  for  inclusion  in  requirements,  decisions,  program 
documents,  and  specifications. 

(5)  Task  5.  Supportability  and  Supportability  -  Related  Design  Factors  — 
This  task  is  designed  to  establish: 

(a)  Quantitative  support  characteristics  of  alternative  design  and 
operational  concepts. 

(b)  Support  and  support  -  related  design  objectives,  goals, 
thresholds,  and  constraints  for  inclusion  in  requirements, 
decisions,  and  program  documents  including  specifications. 

HSI  IN  REQUESTS  FOR  PROPOSALS.  In  addition  to  completing  the  Front-End  Analysis 
to  determine  HSI  objectives,  constraints,  performance  criteria,  etc.,  and  ensuring  that  this 
information  is  included  in  the  major  program  documentation,  two  other  actions  are  most  critical 
in  order  for  HSI  to  successfully  influence  system  design:  (a)  HSI  requirements  must  be  included 
in  the  hardware/software  contractor  RFPs,  and  (b)  HSI  must  be  a  substantial  factor  in  RFP 
source  selections. 


The  RFP  is  the  principal  means  by  which  the  Coast  Guard  communicates  its  materiel 
requirements  to  industry.  There  are  at  least  two  different  categories  of  RFPs  that  are  used  in 
the  acquisition  process: 

a.  RFPs  for  system  hardware/software  designers  and  developers  —  HSI  criteria  and 
requirements  must  be  included  in  these  RFPs  if  HSI  is  to  impact  system  design. 
This  is  the  category  of  RFP  that  will  be  discussed  in  this  document. 

b.  RFPs  for  support  analyses  —  If  the  Coast  Guard  staffs  the  OHSIP  to  perform  the 
HSI  analyses  in-house,  this  type  of  RFP  should  seldom,  if  ever,  be  required. 
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3.1  Hardware/Software  Contractor  Solicitation  Process.  The  solicitation  process  is  an 
extension  of  the  requirements  process,  incorporating  both  the  Program  Sponsor’s  performance 
requirements  and  the  Office  of  Acquisition  program  requirements.  The  solicitation  process  is 
illustrated  in  Exhibit  D-l  and  can  be  viewed  as  the  interrelated  functions  of  solicitation, 


HSI  HSI  HSI 


Exhibit  D-1.  HSI  in  the  Solicitation  Process 


source  selection,  and  contract  award.  The  inclusion  of  HSI  in  requirements,  program,  and 
decision  documents  is  meaningless  unless  this  same  integration  process  occurs  in  solicitation 
documents.  The  objective  is  to  send  a  signal  to  industry  that  the  Coast  Guard  is  serious  about 
HSI  and  that  inclusion  of  human  performance  considerations  into  their  system  design, 
development,  and  production  proposals  is  the  only  way  contractors  can  successfully  bid  Coast 
Guard  acquisition  RFPs. 

a.  The  OHSIP  leads  the  process  of  preparing  HSI  inputs  to  hardware/software 
design,  development,  and  production  RFPs,  assisted  by  the  Program  Sponsor  and 
supported  by  other  specialists  as  required.  Procedures  for  writing  and  processing 
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RFPs  are  well  established  in  the  laws,  regulations,  and  policies  governing 
materiel  acquisition.  The  challenge  is  to  take  the  technological  requirements 
arising  from  an  operational  need  and  convert  them  into  relevant  acquisition 
language  that  is  understood  and  can  be  responded  to  by  industry. 

HSI  requirements  are  refined  into  contractual  language  and  included  in  a 
solicitation  document  such  as  an  RFP.  For  convenience,  we  have  referred  to  the 
period  of  transition  from  requirements  document  to  RFP  as  the  definition  process. 
See  Exhibit  D-2  below. 


Exhibit  D-2.  The  Definition  Process 


During  the  life  cycle  of  a  single  materiel  system,  RFPs  may  be  written  in  several 
acquisition  phases.  There  are  qualitative  differences  in  the  way  HSI  affects  the 
RFP  in  each  phase.  If  HSI  is  to  contribute  to  effective  system  design  its 
influence  must  be  felt  during  the  earliest  acquisition  phases.  Key  design  questions 
(for  example,  the  choice  of  crew  size,  and  thus  the  basic  architecture  of  a  system) 
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are  decided  early  and  should  have  HSI  data  for  consideration  from  all  HSI 
domains. 

d.  The  following  five  rules  of  thumb  are  recommended  to  guide  the  RFP  writer  in 
developing  the  HSI  portion  of  any  RFP.  Violation  of  any  of  these  rules  of  thumb 
invites  deficiencies  in  the  ultimate  effectiveness  and  availability  of  the  fielded 
system. 

(1)  Rule  of  Thumb  #1  —  Human  performance  affects  system  performance. 
One  important  part  of  HSI  in  the  RFP  is  to  influence  materiel  design  so 
that  technology,  and  not  the  human,  becomes  the  limiting  factor  in 
achieving  desired  system  effectiveness. 

(2)  Rule  of  Thumb  #2  —  Skill  is  a  function  of  aptitude  and  training.  Aptitude 
consists  of  basic  abilities  inherent  in  the  individual  and  not  readily 
modified  by  training. 

(a)  Training  refers  to  a  series  of  activities,  such  as  verbal  instructions 
and  practice  on  the  job,  which  enables  personnel  to  acquire  skill 
in  performing  tasks  that  must  be  performed  to  accomplish  Coast 
Guard  missions. 

(b)  Training  is  most  effectively  evaluated  in  two  dimensions: 

1  Completeness  —  Covered  everything  the  individual  needed 
to  know. 

2  Sufficiency  —  Enough  instruction  and  practice  for  the 
individual  to  achieve  acceptable  standards  of  performance. 

(c)  Traits  that  make  up  the  quality  called  aptitude  are  stable  over  time. 

(d)  Skill  is  unstable  over  time  due  to  proficiency  decay  as  a  function 
of  time  without  practice.  Proficiency  of  individuals  with  known 
aptitudes  and  training  can  be  measured  at  a  specific  point  in  the 
training  cycle,  and  those  time  and  accuracy  scores  can  be  used  to 
predict  the  level  of  performance  in  other  individuals  with  known 
aptitudes,  training,  and  practice. 

(3)  Rule  of  Thumb  #3  —  Measure  individual  performance  by  time  and 
accuracy.  This  rule  recognizes  that  human  performance  occurs 
simultaneously  in  two  dimensions:  time  and  accuracy. 
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(a)  Measuring  one  without  the  other,  or  measuring  them  both  but 
independently,  will  almost  certainly  produce  a  distorted  picture  of 
reality. 

(b)  This  rule  of  thumb  is  vital  in  developing  any  data  collection  plan. 

(c)  System  design  defects  that  might  have  been  disclosed  early  can  be 
masked  if,  for  example,  performance  data  describes  only  the  time 
to  perform  a  particular  task,  rather  than  both  time  and  accuracy. 

(d)  Operational  Requirements  Documents  should  state  human 
performance  standards  in  terms  of  both  time  and  accuracy.  These 
requirements  should  be  faithfully  translated  into  procurement  and 
testing  documents. 

(4)  Rule  of  Thumb  #4  —  Equipment  design  determines  personnel  tasks.  This 
rule  of  thumb  recognizes  that  the  equipment  designer  has  the  power  both 
to  create  and  to  eliminate  human  performance  tasks. 

(a)  A  system  may  involve  very  simple  equipment  and  software 
attended  by  numerous  and  highly  skilled  operators,  or  the  system 
may  use  highly  automated  equipment  with  few  operators  of  much 
less  skill. 

(b)  Tasks  assigned  by  the  designer  to  the  human  must  be  within  the 
capabilities  of  Coast  Guard  personnel.  This  is  the  purpose  of 
providing  the  Target  Audience  Description  to  the  designer  early  in 
the  process. 

(5)  Rule  of  Thumb  #5  —  Make  the  designer  responsible  for  human 
performance.  This  rule  tracks  from  rule  #4  because  the  contractor’s 
designer  determines  the  human  tasks  for  operators  and  maintainers  of  any 
system.  Since  the  designer  has  the  power,  he  should  have  the 
responsibility  and  be  accountable  for  exercising  that  power  in  a  way  that 
is  consistent  with  capabilities  and  limitations  of  Coast  Guard  personnel. 

Translating  sponsor  requirements  into  RFP  language  —  If  any  one  of  the 

following  four  requirements  is  missing  from  the  ORD,  it  must  be  created  and 

included  at  the  appropriate  location  in  the  RFP. 

(1)  Performance  requirements  expressed  in  objective,  quantitative  terms 

(2)  Maximum  tolerable  training  burden  (in  terms  of  time  and  cost) 
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(3)  Likely  aptitudes  of  system  operators,  maintainers,  and  support  personnel 

(4)  Directed  limitations  on  manpower  (e.g.,  crew  size  shall  be  no  more  than 
three)  or  organizational  constraints 

(5)  Safety  and  Health  Hazards 


Exhibit  D-3  depicts  how  HSI  requirements  drive  the  system  design. 


(1)  Note  that  the  four  basic  HSI  requirements  make  direct  inputs  to 
development  of  the  various  system  concepts  that  form  the  foundation  for 
system  design. 


D-13 


(2)  Each  system  concept  is  then  evaluated  to  determine  if  the  human  structure 
defined  in  the  Target  Audience  Description  can  meet  the  system 
performance  specification. 

(a)  If  the  answer  is  yes,  the  design  can  continue. 

(b)  If  the  answer  is  no,  then  the  system  concepts  must  be  modified  or 
replaced. 

g.  Personnel  performance  standards  in  the  requirements  above  are  used  by  RFP 
drafters  to  set  parameters  for  trade-off  analyses  to  be  performed  by  contractors. 
See  Exhibit  D-4  for  a  trade-off  example. 


LM3ESRABLE  DESIGN  TRADEOFF 

RANGE.  OF 


DESIGN  CONCEPT  B 


DESIRABLE  DESIGN  TRADEOFF 
RANGE  OF 


RANGE  OF 
ACCEPTABLE  HUMAN 


trajnng  burden 

DESIGN  CONCEPT  A 


Exhibit  D-4.  Example  of  Aptitude,  Training,  and  Human 
Performance  Trade-Offs 


(1)  Note  that  design  concept  A  in  Exhibit  D-4  is  a  desirable  design  trade-off 
because  the  system  produces  high  performance  with  low  personnel 
aptitude  and  a  low  training  burden. 

(2)  Design  concept  B  is  an  undesirable  design  trade-off  because  the  system 
produces  low  performance,  while  requiring  high  personnel  aptitude  and  a 
high  training  burden. 
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It  is  important  to  the  success  of  the  HSI  Program  that  the  Project  Manager 
coordinate  the  hardware/software  contractor  RFPs  with  the  office  responsible  for 
the  HSI  Program,  Program  Sponsor,  and  ILS  Manager.  Coordination  should 
occur  before  technical  requirements  are  submitted  to  the  contracting  officer. 

HSI  in  the  RFP  structure  —  There  are  at  least  six  places  in  the  RFP  format  where 
HSI  matters  should  be  included. 

(1)  Executive  Summary  —  Explains  to  senior  industry  personnel  the  major 
emphasis  in  the  procurement,  and  should  make  clear  the  role  of  HSI  in 
source  selection. 

(2)  Statement  of  Work  —  States  what  the  Coast  Guard  wants  the  contractor 
to  do  (i.e.,  task  statements),  and  describes  deliverables  to  be  procured,  as 
well  as  work  to  be  done  to  ensure  that  the  system  performs  as  specified. 

(3)  System  Specification  —  Describes  how  system  hardware  and  software  is 
supposed  to  appear  and  perform,  and  how  appearance  and  performance 
are  to  be  verified. 

(4)  Contract  Data  Requirements  List  (CDRL)  —  Explains  what  information 
(often  reports)  the  contractor  will  be  required  to  furnish,  how  often,  and 
in  what  form. 

(5)  Instructions  to  Offerors  (Section  L)  —  Helpful  hints  to  help  offerors  write 
more  responsive  proposals. 

(a)  May  include  coordination  statements  (e.g.,  that  the  HSI  and  ILS 
programs  should  not  be  conducted  in  duplicative  fashion). 

(b)  Should  also  include  instructions  on  what  specific  matters  must  be 
covered  in  the  technical  proposal.  Since  HSI  is  an  integration 
effort,  offerors  will  be  instructed  to  address  HSI  as  a  separate 
major  area  and  in  every  applicable  portion  of  their  proposals. 

(6)  Proposal  Evaluation  Criteria  (Section  M)  —  Explains  how  an  offeror’s 
technical  proposal  will  be  evaluated  by  the  Source  Selection  Evaluation 
Board  (SSEB),  and  will  include  both  technical  criteria  and  relative 
importance  of  HSI  compared  to  the  other  separate  major  areas. 

The  RFP  writer  should  prepare  specific  HSI  requirements  for  each  of  the  six 
elements  of  the  RFP  above.  HSI  requirements  should  be  well  balanced  between 
each  element. 
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(1)  The  impact  of  HSI  requirements  is  enhanced  by  linking  them  to  the 
proposal  award  evaluation  factors.  This  is  done  in  Section  L  (Instructions 
and  Conditions  and  Notices  to  Offerors)  and  in  Section  M  (Evaluation  and 
Award  Factors). 

(2)  Emphasis  on  HSI  in  Sections  L  and  M  reflects  the  degree  of  importance 
that  the  Coast  Guard  attaches  to  HSI.  This  emphasis  can  also  be 
summarized  and  conveyed  to  industry  in  the  Executive  Summary. 

3-2  HSI  in  Source  Selection.  We  recommend  that  HSI  be  treated  as  a  separate  major  area  in 
source  selections  with  the  same  visibility  as  technical,  management,  and  cost,  and  that  HSI  be 
evaluated  throughout  all  aspects  of  design,  development,  integrated  logistic  support,  and  program 
management.  Using  this  basic  philosophy,  treatment  of  HSI  should  be  tailored  to  suit  the  nature 
and  priorities  of  the  program  and  contract  effort.  An  acceptable  method  of  criteria  weighing  is 
shown  in  Exhibit  D-5  below.  Because  HSI  is  evaluated  separately  and  throughout,  evaluators 
are  cautioned  to  avoid  double  counting. 


TOTAL  EVALUATION  WEIGHTING  (100%)) 


AREA 

LEVEL 


ELEMENT 

LEVEL 


FACTOR 

LEVEL 


Exhibit  D-5.  HSI  in  Source  Selection  Evaluation 
a.  Procedures  in  the  Solicitation 


(1)  The  Statement  of  Work  and  the  specifications  should  contain  appropriate 
HSI  requirements.  In  particular,  the  specification  should  describe  how  the 
system  is  to  look  and  act  to  the  user  and  how  the  requirements  will  be 
verified. 

(2)  Offerors  should  be  instructed  by  the  solicitation  to  address  HSI  in  every 
applicable  portion  of  their  offers  and  as  a  separate  major  area. 

(3)  Offerors  should  be  informed  in  the  evaluation  and  award  factors  section 

of  the  overall  importance  of  HSI  evaluation  relative  to  other  separate 
major  areas. 
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(4)  All  RFPs  should  contain  a  requirement  for  a  contractor  HSI  Management 
Plan  to  be  provided  as  part  of  the  contractor  proposal. 

b.  Structure  of  the  Source  Selection  Evaluation  Board  (SSEB) 

(1)  The  SSEB  should  be  structured  to  establish  and  maintain  HSI 
considerations  as  a  visible  part  of  the  process.  HSI  should  be  considered 
across  all  major  evaluation  areas,  as  both  a  major  area  and  as  an 
integrating  effort.  Exhibit  D-6  is  an  example  demonstrating  how  properly 
weighted  HSI  considerations  can  impact  the  "best  value"  approach  to 
selection  of  competing  systems. 


Exhibit  D-6.  The  Best  Value  Approach 


4.  COST  DETERMINATION.  Exhibit  D-7  displays  total  system  life-cycle  cost  (LCC)  to 
include  the  program  acquisition  costs  to  build  the  system,  plus  the  ownership  costs  of  operating 
and  maintaining  the  fielded  system. 

a.  LCC  includes  the  cost  of  designing  and  developing  both  hardware  and  software, 
production  of  the  new  equipment,  and  logistics  support  for  the  life  of  the  system, 
including  primarily  personnel  and  maintenance  support  training.  These  costs  are 
cumulative  through  development,  acquisition,  operation,  support  and,  where 
applicable,  disposal. 

b.  Note  from  the  graphic  that  LCC  includes  flyaway /rollaway/sailaway  costs,  plus 
system  procurement,  program  acquisition,  as  well  as  operating  and  support  costs. 

c.  Operations  support  (i.e.,  ownership  costs)  includes  all  types  of  support  required 
to  operate/maintain  the  system  over  its  life  cycle  from  time  of  fielding  to 
disposal.  Ownership  costs  vary  significantly,  may  exceed  acquisition  costs,  and 
include  the  following: 
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PLUS 

•  OPERATIONS 
SUPPORT 


Exhibit  D-7.  Life-Cycle  Cost  Composition 


Personnel  to  operate  and  maintain  the  system,  including  all  required 
maintenance  levels  (i.e.,  organizational  ,  intermediate,  and  depot-level 
maintenance)  —  Also  includes  personnel  retirement  and  health  care  costs 

Training  for  all  operators  and  maintainers  at  all  maintenance  levels 

Replenishment  parts  for  the  system 

Costs  to  house  the  system  and  all  levels  of  maintenance  support  (e.g., 
dedicated  and  shared  test  equipment  and  maintenance  facilities) 

Cost  to  dispose  of  the  system  when  its  useful  life  is  expended 

4- 1  •  Determining  Ownership  Costs.  Personnel  and  training  costs  make  up  the  major  ownership 
costs  once  the  system  is  fielded. 

a.  It  is  critical  to  include  ownership  costs  in  evaluating  and  selecting  the  most  cost 
effective  design  alternative.  This  requires  ownership  costs  to  be  determined  for 
each  design  alternative  as  part  of  the  Front-End  Analysis.  Providing  this  level 
of  detail  requires  adequate  analyst/contract  funding  support  for  early  Front-End 
Analysis. 


'Also  called  rollaway  and  sailaway  cost 

(1) 

(2) 

(3) 

(4) 

(5) 


PLUS 


•  MANAGEMENT 

•  HARDWARE 

•  SOFTWARE 

•  NONRECURRING  “STARTUP* 

•  ALLOWANCE  FOR  CHANGES 

FLYAWAY  COST  # 


•  TECH  DATA 

•  PUBLICATIONS 

.  CONTRACTOR  SERVICES 

•  SUPPORT  EQUIP 

•  TRAINING  EQU*> 

•  FACTORY  TRAINING 


SYSTEM  COST 


PLUS 

•  INITIAL  SPACES 


PROCUREMENT  COST 


PLUS 

•  RDT  &  E 

•  FACILITY 
CONSTRUCTION 


PROGRAM  ACQUISITION  COST 


LIFE  CYCLE  COST 
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b.  Failure  to  develop  accurate  ownership  costs  in  making  system  design  concept 
decisions  results  in  selecting  a  design  approach  without  adequate  consideration  of 
full  life-cycle  cost  and  is  a  very  costly  way  of  doing  business. 

c.  Best  Value  Approach  to  Cost  Determination  —  Exhibit  D-6  demonstrates  a 
method  of  comparing  system  performance  to  life-cycle  costs  for  three  design 
alternatives  to  arrive  at  die  alternative  that  represents  the  best  value  to  the  Coast 
Guard  between  the  three  designs. 

(1)  Note  that  Design  A  produces  one  of  the  highest  system  performance  levels 
with  the  lowest  human  ability  requirements,  but  is  the  most  costly. 

(2)  Design  C  is  the  least  costly,  but  produces  the  lowest  system  performance 
and  the  highest  human  ability,  while  Design  B  falls  between  Designs  A 
and  C. 

(3)  Considerations  in  determining  best  value  to  the  Coast  Guard  include  the 
following: 

(a)  To  be  acceptable  design  alternatives,  all  three  designs  should  meet 
the  minimum  required  system  performance  level.  So  the  issues  in 
the  least  expensive  alternative,  Design  C,  are:  Is  the  human 
ability  level  in  Design  C  achievable?  If  the  human  ability  level  in 
Design  C  cannot  be  completely  met,  is  the  resulting  degradation 
of  system  performance  acceptable? 

(b)  Design  B  falls  in  the  mid-range  of  human  ability,  which  is 
presumably  achievable  without  undue  stress  on  the  personnel 
system.  The  question  then  becomes:  Is  the  increased  system 
performance  worth  the  additional  cost  over  design  C? 

(c)  In  Design  A,  is  either  the  low  human  ability  level  or  the  high 
system  performance  worth  the  added  cost  over  Designs  B  and  C? 

5.  HSI  DOMAIN  PROCESSES.  In  recent  years,  a  number  of  world  class  disasters  have 
occurred,  including  the  nuclear  power  incident  at  Three  Mile  Island,  the  meltdown  at  Chernobyl, 
the  downing  of  KAL-007  by  the  Soviets  and  of  the  Iranian  Airbus  by  the  U.S.S.  Vincennes,  and 
the  inadvertent  poison  gas  release  at  Bhopal.  These  catastrophes  all  had  in  common  the 
fundamental  problem  that  their  high  technology  systems  had  been  designed  with  greater  emphasis 
on  the  equipment  than  the  user.  These  and  other  tragic  accidents  have  been  attributed  to  people 
and  organizations  unable  to  adequately  interpret  and  control  technology.  As  technology  advances 
and  systems  become  more  costly  and  complex,  the  importance  and  complexity  of  human/machine 
interaction  increases.  Nowhere  is  this  more  evident  or  more  critical  than  with  the  high-risk 
technologies  used  by  military  services  such  as  the  Coast  Guard. 
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During  the  1980’s,  the  DoD  Military  Services  recognized  the  increase  in  technology  as  a 
growing  problem  that  required  distinctly  new  approaches  to  ensure  human  system  integration  in 
their  acquisition  processes.  After  nearly  a  decade  of  development,  HSI  emerged  to  address  five 
distinctly  different  aspects  or  domains  of  human  integration  in  system  acquisitions.  The  HSI 
Program  is  a  comprehensive  management  and  technical  initiative  intended  to  enhance  total 
system  performance  by  integrating  human  performance,  reliability,  and  survivability  during 
system  and  equipment  design,  development,  and  modification.  The  goal  of  HSI  is  to 
successfully  integrate  technology  and  people  to  meet  mission  objectives  under  numerous 
environmental  conditions  at  the  lowest  possible  life-cycle  cost.  HSI  promotes  an  increased 
emphasis  on  front-end  planning  to  control  the  impact  of  the  new  system  on  the  human  by 
requiring  consideration  of  issues  related  to  five  domains:  Human  Factors  Engineering,  System 
Safety/Health  Hazards,  Manpower,  Personnel,  and  Training. 

The  following  paragraphs  will  describe  the  essential  elements  of  each  domain.  Commencing 
with  paragraph  5.2,  the  processes  needed  to  adequately  address  each  domain  in  each  acquisition 
will  be  described. 

a.  Human  Factors  Engineering  is  the  application  of  information  derived  from 
human  factors  theory  and  modeling  for  the  specification,  design,  development, 
testing,  analysis,  and  evaluation  of  products  or  systems  for  human  use.  Human 
factors  is  the  body  of  scientific  knowledge  concerned  with  human  capabilities  and 
limitations.  Human  factors  includes  principles  and  applications  of  human 
engineering,  personnel  selection,  training,  life-support,  job  performance  aids,  and 
human  performance  evaluation. 

HFE  is  the  comprehensive  integration  of  design  criteria,  physiological 
characteristics,  psychological  principles,  and  human  capabilities  into  system 
design,  development,  test,  and  evaluation.  The  objective  of  HFE  is  to  optimize 
performance  of  the  human-machine  combination.  This  is  achieved  by  maximizing 
the  ability  of  the  operator/maintainer  to  perform  at  required  levels  by  eliminating 
design-induced  error. 

HFE  considers  all  human  sensory  capability  and  limitations  in  system  design, 
including  identification  of  human  sensory  stimuli,  information  processing,  and 
reaction  or  response  to  the  stimulus.  In  the  design  of  methods  for  presentation 
of  information  (e.g.,  displays  and  controls)  to  Coast  Guardsmen,  the  HFE  applies 
knowledge  of  the  various  human  sensory  mechanisms,  including  their  relative 
capabilities  and  limitations,  to  optimize  the  proposed  human-machine  interface. 
This  interface  can  be  envisioned  as  an  imaginary  surface  across  which  information 
and  energy  are  exchanged  between  the  human  and  machine  components  of  a 
system.  This  domain  is  also  concerned  with  the  cognitive  processes  and  aptitudes 
of  operators  and  maintained  to  evaluate  acceptable  workload  levels,  particularly 
under  stressful  conditions  such  as  those  found  in  rescue,  law  enforcement,  or 
combat  situations. 
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b.  System  Safety  refers  to  the  system’s  ability  to  be  operated  and  maintained 
without  accidental  injury  to  personnel  or  damage  to  the  system.  System  Safety 
involves  the  application  of  engineering,  education,  and  management  principles  and 
techniques  to  design  and  develop  a  system  that  optimizes  safety  within  the 
established  operational,  cost,  and  time  parameters.  Safety  data  is  collected 
through  lessons  learned  on  predecessor  systems  and  mishap  data,  as  well  as 
through  the  use  of  design  trade-off  data.  A  summary  of  the  collected  data 
provides  a  risk  assessment,  a  potential  hazard  classification  for  the  item,  and  a 
list  of  recommended  procedures  or  other  corrective  actions  to  reduce  these 
hazards  to  an  acceptable  level. 

Health  Hazards  involves  the  identification  and  elimination  of  biomedical  hazards 
associated  with  the  system.  A  health  hazard  is  defined  as  an  existing  or  likely 
condition,  inherent  in  the  operation  or  use  of  materiel,  that  can  cause  death, 
injury,  acute  or  chronic  illness,  disability,  and/or  reduced  job  performance. 
These  conditions  can  result  from  either  long-term  or  short-term  exposure  to 
shock,  recoil,  vibration,  noise,  toxic  agents,  radiation,  heat  and  cold,  and/or 
pathogenic  microorganisms.  Similar  to  System  Safety,  the  Health  Hazards 
portion  of  this  domain  seeks  to  improve  total  system  performance  while 
controlling  health  risks  to  the  personnel  who  test,  use,  or  service  Coast  Guard 
systems. 

c.  Manpower  addresses  the  affordability  of  fielding  a  new  materiel  system  in  terms 
of  the  Coast  Guard’s  human  resources  (i.e.,  all  military  billets  and  civilian 
positions).  Affordability  is  determined  by  analyzing  the  applicable  number  and 
quality  of  billets/positions  expected  to  be  authorized  throughout  the  Coast  Guard 
at  the  time  the  new  acquisition  is  fielded,  including  the  manpower  required  by  the 
new  system.  Consideration  of  the  net  effect  of  the  new  materiel  system  on 
overall  Coast  Guard  human  resource  requirements  and  authorizations  is  critical 
to  ensure  the  affordability  of  a  proposed  system.  This  consideration  includes  an 
analysis  of  the  number  and  capabilities  of  people  needed  to  operate,  maintain,  and 
support  the  proposed  system  (based  on  predecessor  or  similar  system  data);  a 
determination  of  changes  generated  by  the  introduction  of  the  system  into  the 
inventory;  and  an  assessment  of  the  impact  these  changes  will  have  on  the  Coast 
Guard’s  manpower  limits  across  all  operational  and  maintenance  levels  affected 
by  the  system. 

d.  Personnel  refers  to  the  aptitudes,  abilities,  and  other  human  characteristics  of 
military  billets  and  civilian  positions.  These  are  the  attributes  necessary  to 
operate,  maintain,  and  support  a  new  materiel  system  and  achieve  optimal  system 
performance  in  peace  and  wartime.  Detailed  analyses  of  personnel  requirements 
for  predecessor  systems,  based  on  system  components,  are  necessary  to  project 
personnel  requirements  for  the  new  system.  The  new  system  is  designed  based 
on  the  personnel  projected  to  be  available  throughout  the  life  cycle  of  the  system. 
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Personnel  analysis  data  must  be  included  in  the  system  life-cycle  cost  estimates 
and  are  needed  in  time  to  allow  for  appropriate  recruitment,  training,  and 
assignment  of  personnel  in  conjunction  with  system  fielding. 

e.  Training  refers  to  the  requisite  knowledge,  skills,  and  abilities  (KSAs)  required 
by  the  available  personnel  to  operate  and  maintain  systems  under  peace  and 
wartime  conditions.  Training  considers  the  time  and  cost  to  provide  necessary 
skills  and  knowledge  through  entry-level  and  sustainment  training  to  qualify  Coast 
Guard  personnel  for  support  of  the  new  system.  Consideration  of  training  needs 
requires  the  formulation  and  selection  of  engineering  design  alternatives  that  are 
supportable  from  a  training  perspective.  It  also  includes  the  identification  of 
resource  requirements,  the  formulation  of  training  strategies,  the  availability  of 
training  resources  (to  include  qualified  instructors  and  proper  equipment),  and  the 
time  needed  for  training  to  be  completed.  These  efforts  are  necessary  to  ensure 
that  adequate  numbers  of  qualified  personnel  will  be  available  for  assignment  to 
the  new  system. 

While  each  domain  focuses  on  separate  issues,  it  is  HSI’s  unique  integration  aspect  that  provides 
the  greatest  benefit  and  promotes  the  practicality  of  the  program.  HSI  includes  the  human  as 
an  integral  element  of  the  new  system  together  with  other  acquisition  factors  such  as  cost,  system 
requirements,  schedule,  reliability,  and  vulnerability.  Trade-offs  and  compromises  performed 
among  these  factors  achieve  a  new  level  of  integration  in  system  design  decisions.  The  five 
domains  of  HSI  integrate  to  form  a  dynamic  organizational  and  management  approach  to  the 
procurement  of  today’s  complex  systems.  Continued  adaptation  and  refinement  of  the  HSI 
concept  will  result  in  lower  life-cycle  cost,  both  in  human  and  financial  terms,  while 
concurrently  enhancing  system  capabilities. 

5.1  HSI  Program  Management  Actions  by  Acquisition  Phase.  We  have  divided  the  various 
actions  required  to  execute  the  HSI  Program,  in  a  given  acquisition,  into  two  types  of  activities: 
program  management  actions  and  technical  actions.  Program  management  actions  are 
management  activities  taken  to  meet  the  objectives  of  the  HSI  Program  and  normally  affect  all 
domains.  Technical  actions  are  those  process-  and  technique-oriented  activities  required  to  carry 
out  the  HSI  Program  in  a  given  domain.  Categorizing  HSI  Program  actions  in  this  manner 
permits  us  to  describe  those  management  and  technical  activities  separately.  We  anticipate  that 
this  arrangement  should  permit  a  reader  to  review  the  management  actions  first  to  grasp  the 
general  pattern  of  HSI  activities  across  the  acquisition  process;  and,  with  that  background,  to 
more  readily  understand  the  detailed  technical  activities  described  for  each  individual  domain. 

Accordingly,  the  following  paragraphs  will  describe  the  program  management  actions  required 
in  each  acquisition  phase.  This  presentation  will  indicate  the  general  flow  of  HSI  activity 
through  the  acquisition  process  and  will  be  followed  by  a  discussion  of  the  technical  actions 
taken  by  each  domain  to  effect  their  portion  of  the  HSI  Program.  See  Exhibit  D-8  for  an 
overview  of  the  HSI  Process. 
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a.  Project  Initiation  Phase. 


(1)  Develop  the  HSI  System  Management  Plan. 

(2)  Provide  inputs  to  the  Major  System  Acquisition  Project  Nomination 
Memorandum  and,  as  necessary,  to  the  Mission  and  Cost  Analysis  and  the 
Technical  Assessment. 

(3)  Initiate  an  HSI  data  base  to  track  the  HSISMP  and  data  from  each  domain. 

(4)  Initiate  the  MAPT1DES  Methodology  and  the  Front-End  Analysis. 

b.  Requirements  Definition  Phase. 

(1)  Provide  HSI  inputs  to  MNS,  strategy  objectives  for  the  AP,  PORD,  and 
for  KDP-1. 

(2)  Make  inputs  as  necessary  to  the  Mission  Functional  Analysis  and  System 
Cost/Effectiveness  Analysis. 

(3)  Update  all  HSI  Program  documentation. 

c.  Concepts  Exploration  Phase. 

(1)  Provide  HSI  inputs  to  the  PORD/ORD,  AP,  PMP,  TEMP,  Integrated 
Logistic  Support  Plan  (ILSP),  RFPs,  and  KDP-2. 

(2)  Provide  HSI  inputs  as  required  to  Feasibility  Studies,  Trade-off  Analysis, 
Development  Test  Plan,  Project  Baseline  Documentation,  Engineering 
Feasibility  Studies,  and  address  critical  Test  and  Evaluation  issues. 

(3)  Provide  life-cycle  cost  estimates  for  each  design  alternative. 

(4)  Update  all  HSI  Program  documentation. 

d.  Demonstration/Validation  Phase. 

(1)  Provide  HSI  inputs  to  update  all  acquisition  program  documentation, 
system  design,  risk  analysis,  and  KDP-3. 

(2)  Provide  HSI  inputs  as  required  to  the  Advanced  Development  Model 
demonstrations  and  validation,  Test  and  Evaluation,  and  subsystem 
Compatibility/Trade-off  Analysis. 
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(3)  Update  all  HSI  Program  documentation. 


e.  Full  Scale  Development  Phase. 

(1)  Provide  HSI  inputs  to  update  all  acquisition  program  documentation, 
system/subsystem  design,  and  KDP-4. 

(2)  Provide  HSI  inputs  as  required  to  the  Operational  Test  Plan,  Operational 
Deployment  Plan,  Engineering  Design  Model,  and  Prototype 
Developmental/Operational  Test  and  Evaluation. 

(3)  Update  all  HSI  Program  documentation. 

f.  Production  Phase. 

(1)  Coordinate  hand-off  of  personnel  and  training  support  plans  to  Coast 
Guard  institutions  providing  life-cycle  support. 

(2)  Provide  HSI  input  to  production  RFPs,  system  acceptance  testing,  First 
Article  Developmental/Operational  Test  and  Evaluation,  ILSP  update, 
OLSP,  and  Operational  Baseline  Configuration  Index. 

(3)  Update  all  HSI  Program  documentation. 

g.  Deployment  Phase. 

(1)  Provide  HSI  input  to  ILSP  and  OLSP  updates,  ILS  Effectiveness 
Assessment,  and  Project  Transition  Plan. 

(2)  Record  lessons  learned  in  all  domains. 

(3)  Preserve  the  HSI  data  bases  in  all  domains  for  use  in  future  acquisitions. 

5.2  Human  Factors  Engineering.  HFE  is  defined  as  the  comprehensive  technical  effort 
required  to  integrate  materiel  development  and  acquisition  into  Coast  Guard  HSI  doctrine  in 
order  to  ensure  system  operational  effectiveness  regarding: 

a.  Human  physical  and  psychological  characteristics 

b.  Anthropometric  data 

c.  System  interface  requirements 

d.  Human  performance 
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e.  Biomedical  factors 

f.  Safety  factors 

g.  Manning 

HFE  deals  with  the  design  of  Coast  Guard  materiel  to  ensure  that  its  use  conforms  to  the 
capabilities  and  limitations  of  the  fully  equipped  range  of  Coast  Guardsmen  that  operate, 
maintain,  supply,  and  transport  the  materiel  in  the  mission  environment.  HFE  is  used  in  system 
definition,  design,  development,  and  evaluation  in  order  to  optimize  the  capabilities  and 
performance  of  human-machine  systems.  These  capabilities  and  limitations  should  be  identified 
early  enough  in  the  design  effort  to  impact  system  development. 

5.2.1  HFE  Objectives.  The  primary  objective  of  HFE  in  the  acquisition  process  is  to  ensure 
that  Coast  Guard  materiel,  and  concepts  for  their  use,  conform  to  the  capabilities  and  limitations 
of  the  fully  equipped  Coast  Guardsman  to  operate,  maintain,  supply,  and  transport  the  materiel 
in  the  operational  environment  in  a  manner  consistent  with  mission  requirements  and  logistical 
capabilities.  Within  the  context  of  Coast  Guard  materiel  acquisition,  HFE  should  include  those 
aspects  of  systems  analysis  that  determine  the  role  of  the  Coast  Guardsman  in  the  system, 
defining  and  developing  human-machine  interface  characteristics,  workplace  layout,  and  work 
environment.  Ideally,  HFE  should  be  applied  during  development  and  acquisition  of  Coast 
Guard  systems  to  achieve  effective  integration  of  personnel  into  system  design  and  serve  as  the 
interface  between  the  five  HSI  domains  and  systems  engineering.  HFE  analyses  pertaining  to 
manning  levels  and  user,  operator,  and  maintainability  requirements  should  be  used  as  inputs 
when  considering  the  Manpower,  Personnel,  and  Training  domains  within  the  materiel 
acquisition  process.  The  HFE  effort  should  seek  to  develop  or  improve  the  personnel- 
equipment/ software  interface,  to  achieve  required  effectiveness  of  human  performance  during 
system  operation/maintenance/control,  and  to  make  economical  demands  upon  personnel 
resources,  skills,  training,  and  costs. 

5.2.2  Key  HFE  Issues  in  Requirements  Development.  Appendix  F  lists  key  HFE  issues  and 
can  be  used  as  a  guide  for  developing  HSI  requirements.  This  list  should  be  tailored  to  the 
specific  needs  of  the  system  under  development.  The  criticality  of  these  key  issues  will  vary  for 
each  system.  Therefore,  OHSIP  should  determine  which  key  issues  are  critical  and  develop 
HFE  documentation  for  inclusion  in  both  contract  and  in-house  program  documents.  This 
documentation  should  be  precise  and  specific  to  ensure  that  contractors  fully  understand  the  HFE 
requirements. 

5.2.3  HFE  Contributions  to  Front-End  Analysis.  FEA  plays  an  important  role  in  generating 
the  information  needed  for  HFE  to  optimally  impact  system  design  and  acquisition.  The  FEA 
process  facilitates  identification  of  HFE  constraints,  performance  criteria,  objectives,  trade-offs, 
risks,  cost  drivers,  and  other  program  documentation  inputs  including  strategy  and  criteria  for 
integrating  HFE  into  design  specifications. 
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In  the  early  (Project  Initiation  and  Requirements  Definition)  phases  of  the  acquisition  process, 
HFE  contributes  to  the  FEA  through  review  of  the  Baseline  Comparison  System.  During  the 
middle  (Concept  Development  and  Demonstration  and  Evaluation)  phases,  well  established  and 
defined  HFE  requirements  should  be  incorporated  into  the  system  design.  In  addition,  these 
same  HFE  requirements  should  be  used  to  update  technical  documentation  and  program 
management  plans.  In  the  later  (Full  Scale  Development,  Production,  and  Deployment)  phases, 
testing  should  be  conducted  to  identify  and  remedy  HFE-related  problems  and  provide 
verification  that  maximum  human-system  effectiveness  has  been  achieved. 

5.2.4  HFE  Processes.  HFE-related  tasks  are  contingent  upon  the  life-cycle  phase  under 
consideration.  As  tasks  are  completed  within  each  phase,  the  products  generated  provide  inputs 
to  the  following  phase.  The  exhibits  referenced  in  this  section  provide  a  systematic  framework 
for  illustrating  the  process  interactions  that  occur  between  these  inputs,  tasks,  and  products  both 
within  and  between  system  phases. 

5.2.5  Applicability.  The  following  paragraphs  describe  the  HFE  processes  (i.e.,  objectives, 
inputs,  tasks,  activities,  and  products)  that  occur  both  within  and  between  the  seven  system 
development  phases.  However,  it  is  not  intended  that  every  HFE  task  or  technique  referenced 
herein  should  be  applied  to  every  program  or  program  phase  of  Coast  Guard  acquisitions. 
Section  B  of  the  Coast  Guard  Human  Systems  Integration  Requirements  Document  entitled, 
Human  Factors  Engineering  Program,  provides  references,  task  descriptions,  and  specific  HFE 
tailoring  guidance. 

5.2.5. 1  Project  Initiation  Phase.  The  major  objective  of  the  HFE  element  of  the  HSI  Program 
within  this  phase  is  to  ensure  that  HFE  issues,  in  coordination  with  those  of  the  other  domains, 
are  afforded  adequate  and  timely  consideration.  HFE  planning  should,  in  concert  with  the 
Front-End  Analysis,  begin  with  a  review  of  the  human  factors  lessons  learned  that  arose  during 
the  development  and  subsequent  deployment  of  the  selected  BCS.  This  review  should  identify 
preliminary  HFE  objectives  and  potential  constraints  relevant  to  the  envisioned  acquisition. 
Exhibit  D-9  illustrates  the  HFE  inputs,  tasks,  and  products  associated  with  this  phase. 

The  HSI  documentation  impacted  by  HFE  in  the  phase  includes: 

a.  HSI  Systems  Management  Plan  —  This  plan  incorporates  specific  HFE  issues 
expected  to  impact  the  readiness,  cost,  or  performance  of  the  new  system. 

b.  Draft  Human  Engineering  Program  Plan  (HEPP)  —  This  plan  includes  the  tasks 
to  be  performed,  HFE  KDPs,  level  of  effort,  HFE  methods  and  techniques  to  be 
used,  HFE  design  concepts  to  be  utilized,  and  the  HFE  test  and  evaluation 
program  in  terms  of  an  integrated  effort  within  the  total  acquisition. 

The  program  documentation  impacted  and  other  products  generated  by  HFE  in  this  phase 
include: 
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Human  Factors  Engineering  Domain 


c 

O)  o  c 
c  .¥>  ± 9 
(5  fl¬ 
ee  p  E 
E  b  2 

LU  O  g> 

LL  Q)  2 
X  C  0- 


CO  ® 
1 1 1  (0 

g  t 

z  < 


0)  o> 

CO  .£ 
CO  E 
cn  0) 
1X1  o 

O)  c 
*o> 
c 

S  LLI 

C  r- 


LJJ  o 


o8  | 

CO  § 
*  o 
CO  . 


<NJ  00  Tj- 


D-28 


Develop  HFE  objectives,  constraints,  performance 
criteria,  trade-offe,  risks,  and  cost  drivers 


a.  Draft  MNS  —  Indicates  that  HFE  techniques  are  to  be  applied  to  the  ongoing 
design  effort.  The  MNS  should  specify  any  expected  or  existing  Human  Factors 
Engineering  constraints. 

b.  Draft  PORD  HFE  requirements  inputs 

c.  Draft  AP  HFE  strategy  objectives  inputs 

d.  Major  System  Acquisition  Project  Nomination  Memorandum 
The  HFE  tasks  associated  with  this  phase  include: 

a.  Contributions  to  the  FEA  through  review  of  lessons  learned  from  the  BCS  to 
clarify  and  identify  preliminary  HFE  objectives  and  constraints,  performance 
criteria,  tradeoffs,  risks,  cost  drivers,  and  the  strategy  and  criteria  needed  to 
integrate  HFE  into  design  specifications. 

b.  HFE  expertise  should  be  included  in  development  of  the  HSI  System  Management 
Plan  to  ensure  that  HFE  issues  are  fully  addressed  and  to  coordinate  efforts  from 
the  other  HSI  domain  representatives  with  systems  engineering. 

5.2.5.2  Requirements  Definition  Phase.  The  major  objective  of  the  HFE  element  of  HSI 
within  this  program  phase  is  to  define  the  HFE  systems  requirements.  Exhibit  D-10  illustrates 
the  HFE  inputs,  tasks,  and  products  associated  with  this  phase. 

The  HSI  documentation  impacted  by  HFE  in  the  phase  includes: 

a.  Draft  HEPP  update 

b.  HFE  inputs  to  HSISMP 

The  program  documentation  impacted  and  other  products  generated  by  HFE  in  this  phase 
include: 

a.  HFE  inputs  to  MNS,  strategy  objectives  for  the  AP,  PORD,  and  KDP-1 

b.  HFE  inputs  as  necessary  to  the  mission  functional  analysis  and  system 
cost/effectiveness  analysis 

The  HFE  tasks  associated  with  this  phase  include  FEA  (BCS  review  continues).  This  process 
refines  HFE  system  objectives  and  constraints. 

5.2.5. 3  Concepts  Exploration  Phase.  Following  the  evaluation  of  alternative  system  concepts 
and  the  selection  of  preferred  concepts,  the  major  HFE  objective  within  this  acquisition  phase 
is  to  define  HFE  requirements.  Exhibit  D-ll  illustrates  the  HFE  inputs,  tasks,  and  products 
associated  with  this  phase. 

The  HSI  documentation  impacted  by  HFE  in  the  phase  includes: 
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Exhibit  D-10.  Human  Factors  Engineering  in  the  Requirements  Definition  Phase 
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Exhibit  D-1 1 .  Human  Factors  Engineering  in  the  Concept  Exploration  Phase 


a.  HEPP 

b.  Refined  HFE  system  objectives  and  constraints 

c.  HFE  inputs  to  HSISMP 

The  program  documentation  impacted  and  other  products  generated  by  HFE  in  this  phase 
include: 

a.  MNS  update 

b.  HFE  strategy  objectives  for  the  AP,  PORD,  and  KDP-2. 

The  following  HFE  tasks  and  techniques  are  associated  with  this  phase.  FEA  (BCS  review)  is 
also  continued. 

a.  Analysis  of  Similar  Systems:  An  analysis  that  is  analogous  to  the  BCS  review  of 
relevant  reference  systems. 

b.  Functional  Allocation:  A  task  that  determines  whether  a  particular  system 
function  or  role  should  be  assigned  to  the  machine  or  human  element. 

c.  Functional  Flow  Analysis:  This  analysis  models  system  activities  in  a  sequential 
manner  and  describes  their  interrelationships  in  a  top-down  manner. 

d.  Decision-Action  Analysis:  The  detailed  steps  inherent  in  this  technique  permit 
the  identification  of  potential  cost  drivers,  training  requirements,  manning  levels, 
etc. ,  and  is  of  value  in  determining  trade-offs. 

e.  Task  Analysis:  A  detailed  system  development  process  concerned  with  the 
identification  and  description  of  system  tasks  as  related  to  training  plans  and 
programs,  operator  workload,  etc. 

f.  Time-Line  Analysis:  A  technique  related  to  functional  flow  analysis  that  serves 
two  purposes:  (1)  determines  the  time  required  to  adequately  perform  mission 
activities  and  (2)  identifies  where  additional  data  is  required  regarding  mission 
activities. 

g.  Workload  Analysis:  A  technique  performed  to  determine  operator  task  loading 
and  the  extent  to  which  performance  is  impacted  and  affects  decisions  regarding 
task  reassignment,  hardware  redesign,  etc. 
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h.  Operational  Sequence  Analysis:  One  of  the  most  powerful  analytic  techniques 
that  is  useful  in  multi-operator  and  multi-machine  system  designs.  This  technique 
identities  critical  activities  that  can  alter  the  nature  of  the  envisioned  tasks. 

i.  Controlled  Experimentation:  An  efficient  data  gathering  technique  that  allows  for 
the  establishment  of  causation  in  the  investigation  of  HFE-related  issues. 

j.  Walk  Through:  A  technique  useful  at  various  points  in  the  design  process  for 
stepping  through  task  procedures,  documents,  functional  flows,  computer 
programs,  etc.,  to  determine  omissions  in  procedures,  discontinuities,  and 
inconsistencies. 

k.  Simulation:  Modeling  of  system-operator  tasks  and  activities  to  discern  potential 
difficulties  that  may  arise  in  the  fielded  system. 

l.  Mission  Profile:  A  pictorial  or  graphical  representation  that  shows  how  the 
functions  of  the  envisioned  mission  change  over  time. 

m.  Mission  Scenario:  A  narrative  account  detailing  a  system’s  anticipated 
performance  and  accounting  for  personnel,  activities,  and  mission  environment. 

5.2.5. 4  Demonstration  and  Validation  Phase.  The  major  HFE  objective  within  this  program 
phase  is  to  develop  and  validate  the  selected  HFE  system  concepts  and  to  reduce  technical  risk 
to  acceptable  levels.  Exhibit  D-12  illustrates  the  HFE  inputs,  tasks,  and  products  associated  with 
this  phase. 

The  HSI  documentation  impacted  by  HFE  in  the  phase  includes: 


a.  HEPP 

b.  HFE  inputs  to  HSISMP 

c.  HFE  Test  and  Evaluation  Requirements  developed. 

The  program  documentation  impacted  and  other  products  generated  by  HFE  in  this  phase 

include: 

a.  HFE  inputs  to  MNS,  strategy  objectives  for  the  AP,  PORD,  and  for  KDP-3. 

b.  HFE  inputs  as  necessary  to  the  Mission  Functional  Analysis  and  System 
Cost/Effectiveness  Analysis. 

The  HFE  tasks  associated  with  this  phase  include: 
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a.  Complete  BCS  Review  and  Analyses  of  Similar  Reference  Systems 

b.  Functional  Allocation 

c.  Functional  Flow  Analysis 

d.  Decision-Action  Analysis 

e.  Task  Analysis 

f.  Time-Line  Analysis 

g.  Workload  Analysis 

h.  Operational  Sequence  Analysis 

i.  Controlled  Experimentation 

l.  Analysis  of  Similar  Systems 

m.  Mission  Profile 

n.  Mission  Scenario 

o.  Walk  Through 

p.  Fault  Tree  Analysis:  A  technique  suited  for  analyzing  system  failure  antecedants 
in  order  to  identify  and  subsequently  correct  them. 

q.  Failure  Mode  and  Effect  Analysis:  An  HFE  technique  performed  in  the  earlier 
stages  of  system  acquisition  that  concentrates  on  identifying,  describing,  and 
classifying  potential  system  failures. 

5.2.5.5  Full  Scale  Development  Phase.  The  major  HFE  objective  in  this  program  phase  is  to 
finalize  HFE  contributions  to  system  design  and  prepare  for  production.  Exhibit  D-13  illustrates 
the  HFE  inputs,  tasks,  and  products  associated  with  this  phase. 

The  HSI  documentation  impacted  by  HFE  in  the  phase  includes: 

a.  HSISMP 

b.  HEPP 
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Exhibit  D-13.  Human  Factors  Engineering  in  the  Full  Scale  Development  Phase 


The  program  documentation  impacted  and  other  products  generated  by  HFE  in  this  phase 
include: 

a.  HFE  inputs  as  required  to  update  all  acquisition  program  documentation, 
system/subsystem  design,  and  KDP-4 

b.  HFE  inputs  as  required  to  the  Operational  Test  Plan,  Operational  Deployment 
Plan,  Engineering  Design  Model,  Prototype  Developmental/Operational  Test  and 
Evaluation 

The  HFE  tasks  associated  with  this  phase  include: 

a.  Walk  Through 

b.  Link  Analysis:  A  technique  useful  in  designing  the  layout  of  instruments  or 
consoles.  Its  goal  is  the  minimization  of  hand  movements,  eye  movements,  etc., 
required  to  perform  system  tasks  and  operations. 

c.  Simulation 

d.  Fault  Tree  Analysis 

e.  Failure  Mode  and  Effect  Analysis 

f.  Activity  Analysis:  A  technique  that  determines  how  time  is  allocated  to  system 
tasks.  It  is  another  data  collection  technique  used  when  an  experiment  is  not 
appropriate. 

g.  Critical  Incident  Study:  A  technique  useful  in  determining  accident  provocative 
situations  inherent  in  systems.  It  proposes  methods  for  their  elimination  or 
amelioration. 

h.  Questionnaire:  A  data  collection  technique  useful  as  an  adjunct  to  other 
techniques  that  provides  system  operator  and  other  respondent  reports  for 
consideration  during  any  phase  of  system  development. 

i.  Interview:  A  data  collection  technique  similar  to  the  questionnaire  except  that  the 
data  collector  has  one-on-one  contact  with  the  system  operator  or  respondent. 


5. 2.5. 6  Production  Phase.  The  major  HFE  objective  in  this  phase  is  to  address  any  design 
changes  affecting  human  performance  that  involve  conceptual,  validation,  or  full  scale 
engineering  development  HFE-related  tasks.  Exhibit  D-14  illustrates  the  HFE  inputs,  tasks,  and 
products  associated  with  this  phase. 
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Exhibit  D-14.  Human  Factors  Engineering  in  the  Production  Phase 


The  program  documentation  impacted  or  products  generated  by  HFE  in  this  phase  include  HFE 
inputs  as  required  to  production  RFPs,  system  acceptance  testing,  First  Article 
Developmental/Operational  Test  and  Evaluation,  ILSP  update,  OLSP,  and  Operational  Baseline 
Configuration  Index. 

The  HFE  tasks  associated  with  this  phase  include: 

a.  Walk  Through 

b.  Simulation 

5.2.5.7  Deployment  Phase.  The  major  HFE  objective  in  this  phase  is  to  identify  the  HFE 
lessons  learned  and  to  update  the  lessons-leamed  data  base  for  reference  during  future 
acquisitions.  Exhibit  D-15  illustrates  the  HFE  inputs,  tasks,  and  products  associated  with  this 
phase. 

The  HSI  documentation  impacted  by  HFE  in  the  phase  includes: 

a.  HSISMP 

b.  HFE  inputs  into  lessons-leamed  data  base 

The  program  documentation  impacted  or  products  generated  by  HFE  in  this  phase  include  HFE 
applicable  updates  to  the  ILSP  and  OLSP,  ILS  Effectiveness  Assessment,  and  Project  Transition 
Plan. 

The  HFE  tasks  associated  with  this  phase  include: 

a.  Link  Analysis 

b.  Simulation 

c.  Activity  Analysis 

d.  Critical  Incident  Studies 

e.  Questionnaire 

f.  Interview 

g.  Accident  Investigation:  A  means  of  ascertaining  system  failures.  It  draws  heavily 
on  other  HFE  techniques  (e.g.,  simulation,  critical  incident  technique,  interview, 
etc.,)  to  reach  conclusions  regarding  the  nature  of  the  failure. 
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5.3  System  Safetv/Health  Hazard  (SS/HH)  Domain.  The  philosophy  underlying  the  application 
of  the  SS/HH  domain  in  system  design  considers  protection  of  both  human  and  equipment 
elements  to  be  a  critical  component  of  system  efficiency,  mission  effectiveness,  and  reduced  life- 
cycle  cost. 

5.3.1  System  Safetv/Health  Hazards  Domain  Objectives.  System  Safety  Engineering  (SSE) 
identifies,  evaluates,  and  eliminates  or  controls  System  Safety  and  Health  Hazards  in  the  design 
and  development  of  Coast  Guard  materiel  systems. 

a.  System  Safety  involves  the  application  of  both  engineering  and  management 
principles,  criteria,  and  techniques  to  optimize  safety  within  the  constraints  of 
operational  effectiveness,  time,  and  cost  throughout  all  phases  of  the  new  materiel 
system’s  life  cycle.  It  involves  the  identification  of  hazards  and  their  elimination, 
or  adequate  control.  System  Safety  management  ensures  the  planning, 
implementation,  and  completion  of  tasks  and  activities  to  meet  System  Safety 
requirements,  consistent  with  overall  program  goals.  Safety  considerations  are 
incorporated  into  the  human-machine  interface  design  (to  satisfy  stated  tasks, 
conditions,  and  standards)  and  into  test  and  evaluation. 

b.  The  Health  Hazards  portion  of  the  domain  involves  the  application  of  biomedical 
and  psychological  knowledge  and  principles  to  identify,  evaluate,  and  eliminate 
or  control  risks  to  the  health  and  effectiveness  of  personnel  who  test,  operate, 
maintain,  and  support  new  materiel  acquisitions.  A  Health  Hazard  is  defined  as 
any  existing  or  likely  condition,  inherent  in  the  operation  or  use  of  materiel,  that 
can  cause  death,  injury,  acute  or  chronic  illness,  disability,  or  reduced  job 
performance  by  exposure  to: 

(1)  Acoustical  energy 

(2)  Biological  substances 

(3)  Chemical  substance 

(4)  Oxygen  deficiency 

(5)  Psychological  stresses 

(6)  Radiation  energy 

(7)  Shock 

(8)  Temperature  extremes  and  humidity 

(9)  Trauma 
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Exhibit  D-15.  Human  Factors  Engineering  in  the  Deployment  Phase 


(10)  Vibration 


5*3*2  SS/HH  Prcc?d?ncc.  The  order  of  precedence  for  satisfying  System  Safety  requirements 
and  resolving  identified  hazards  is: 

a.  Designing  to  eliminate  risk 

b.  Designing  for  minimum  risk 

c.  Incorporating  safety  devices 

d.  Providing  warning  devices 

e.  Development  of  procedures  and  training 

5*3-3  SS/HH  Domain  Activities.  SS/HH  domain  contributions  to  system  design  are  necessarily 
contingent  upon  the  life-cycle  phase  under  consideration.  In  the  early  (Project  Initiation  and 
Requirements  Definition)  phases,  the  SS/HH  domain  contributes  to  the  FEA  through  a  review 
of  the  BCS  and  other  relevant  reference  systems. 

The  FEA  plays  an  important  role  in  generating  the  information  needed  for  the  SS/HH  domain 
to  optimally  impact  system  design  and  acquisition.  The  FEA  process  facilitates  identification 
of  SS/HH  requirements,  objectives,  constraints,  criteria,  trade-offs,  risks,  cost  drivers,  and  other 
program  documentation  inputs  including  strategy  and  criteria  for  integrating  SS/HH 
considerations  into  design  specifications  and  hardware/software  contractor  RFPs.  During  the 
middle  (Concept  Development  and  Demonstration  and  Evaluation)  phases,  well  established  and 
defined  SS/HH  requirements  should  be  incorporated  into  the  technical  documentation,  program 
management  plans,  and  hardware/software  contracts.  In  the  later  (Full  Scale  Development, 
Production,  and  Deployment)  phases,  testing  should  be  conducted  to  identify  and  remedy 
unresolved  SS/HH-related  problems  and  to  verify  that  SS/HH  goals  have  been  achieved. 

5-3*4  SS/HH  Domain  Processes.  Within  this  section,  SS/HH  objectives  and  recommended 
processes  are  presented  for  each  of  the  seven  system  design  and  development  phases,  since 
SS/HH  domain  processes  (i.e.,  the  phase-specific  tasks,  and  related  products  that  give  direction 
to  the  SS/HH  program)  are  contingent  upon  the  life-cycle  phase  under  consideration.  As  tasks 
are  completed  within  each  program  phase,  the  products  generated  provide  inputs  to  the  following 
phase.  Accordingly,  the  exhibits  referenced  in  and  supported  by  the  following  paragraphs 
provide  a  framework  for  illustrating  the  SS/HH  domain  process  interactions  that  occur  between 
these  inputs,  tasks,  and  products,  both  within  and  between  acquisition  phases. 

5.3.5  Applicability.  The  following  paragraphs  describe  SS/HH  domain  processes  (i.e., 
objectives,  inputs,  tasks,  activities,  and  products)  that  occur  both  within  and  between  the  seven 
system  development  phases.  The  SS/HH  tasks  described  in  the  following  paragraphs  are  based 
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largely  upon  MIL-STD-882B,  System  Safety  Program  Requirements,  and  can  be  imposed  on 
contractors  or  in-house  design  activities  to  direct  and  define  the  conduct  of  a  SS/HH  program 
across  the  system  design  life  cycle.  However,  it  is  not  intended  that  all  of  the  tasks  listed  in  the 
following  exhibits  should  be  applied  to  every  program  or  program  phase.  To  achieve  safe,  cost 
effective  acquisition  and  life-cycle  ownership  of  Coast  Guard  materiel,  tasks  should  be 
specifically  tailored  to  each  acquisition.  Section  C  of  the  Coast  Guard  Human  Systems 
Integration  Program  Requirements  Document  provides  references  and  detailed  amplification  of 
MIL-STD-882B  tasks. 

5  3  51  Project  Initiation  Phase.  The  major  objective  of  the  SS/HH  element  in  this  phase  is 
to  establish  and  maintain  a  System  Safety  Program  to  ensure  that  SS/HH  issues,  in  coordination 
with  those  of  the  other  domains,  are  afforded  adequate  and  timely  consideration.  SS/HH 
planning  should,  in  concert  with  the  Front-End  Analysis,  begin  with  a  review  of  the  SS/HH 
lessons  learned  that  arose  during  the  development  and  subsequent  deployment  of  the  selected 
Baseline  Comparison  System.  This  review  should  facilitate  identification  of  preliminary  SS/HH 
objectives  and  potential  constraints  relevant  to  the  envisioned  acquisition.  Exhibit  D-16 
illustrates  the  SS/HH  domain  inputs,  tasks,  and  products  associated  with  this  phase. 

The  HSI  documentation  impacted  by  the  SS/HH  domain  in  this  phase  includes: 

a.  HSI  Systems  Management  Plan:  Specific  HH/SS  domain  inputs  to  this  document 
include  the  content  and  timeframe  for  completing  the  various  SS/HH  plans  and 
analyses  for  identifying  and  eliminating  or  controlling  safety  issues  and  Health 
Hazards  in  the  new  acquisition. 

b.  Draft  System  Safety  Program  Plan  (SSPP):  This  plan  serves  as  the  basic  tool  to 
be  used  by  the  OHSIP  in  managing  an  effective  SS/HH  program.  The  SSPP 
should  identify  all  Coast  Guard-specified  safety  program  activities  and  show  how 
the  SS/HH  program  will  provide  input  or  preclude  duplication  of  effort. 

The  program  documentation  impacted  and  the  products  generated  in  this  phase  include: 

a.  Draft  MNS:  The  MNS  should  specify  any  expected  or  existing  safety  and  hazard 
control  constraints  and  the  action  proposed  to  eliminate  or  reduce  those  risks. 

b.  Draft  PORD/ORD  SS/HH  requirements  input. 

c.  Draft  AP  SS/HH  strategy  objectives  input. 

The  SS/HH  tasks  associated  with  this  phase  include: 

a.  Contributions  to  the  FEA  through  review  of  lessons  learned  from  the  BCS  to 
clarify  and  identify  preliminary  SS/HH  objectives  and  constraints,  performance 
criteria,  trade-offs,  risks,  cost  drivers,  and  the  strategy  and  criteria  needed  to 
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Exhibit  D-16.  SS/HH  in  Project  Initiation  Phase 


integrate  SS/HH  design  contributions  into  system  specifications. 

b.  SS/HH  domain  expertise  should  be  contributed  to  OHSIP  in  development  of  the 
HSI  System  Management  Plan  to  ensure  that  SS/HH  issues  are  fully  addressed 
and  to  ensure  that  applicable  SS/HH  tasks  are  imposed  as  part  of  the  system 
design  effort. 

5. 3.5.2  Requirements  Definition  Phase.  The  major  objective  of  the  SS/HH  element  of  the  HSI 
Program  in  this  acquisition  phase  is  to  further  refine  objectives,  constraints,  and  SS/HH 
requirements.  Exhibit  D-17  illustrates  the  SS/HH  domain  inputs,  tasks,  and  products  associated 
with  this  phase.  The  HSI  documentation  impacted  by  the  SS/HH  domain  in  this  phase  includes: 

a.  Draft  SSPP  update 

b.  SS/HH  domain  inputs  to  HSISMP 

The  program  documentation  impacted  and  the  products  generated  in  this  phase  includes: 

a.  SS/HH  inputs  to  MNS,  strategy  objectives  for  the  AP,  PORD,  and  KDP-1 

b.  SS/HH  domain  inputs  as  necessary  to  the  mission  functional  analysis  and  system 
cost/effectiveness  analysis 

The  SS/HH  domain  tasks  associated  with  this  phase  include: 

a.  FEA  (BCS  review  continues)  —  Refines  SS/HH  system  objectives  and  constraints 

b.  Draft  SSPP  update 

5. 3.5. 3  Concepts  Exploration  Phase.  The  major  objective  of  the  SS/HH  element  in  this  phase 
is  to  evaluate  each  alternative  system  concept  to  identify  SS/HH  limitations  and  objectives  given 
the  existing  systems,  programs,  and  force  structure.  See  Exhibit  D-18  on  the  following  page. 

The  HSI  documentation  impacted  by  the  SS/HH  domain  in  this  phase  includes: 

a.  SSPP 

b.  Refined  SS/HH  domain  system  objectives  and  constraints 

c.  SS/HH  inputs  to  HSISMP 

The  program  documentation  impacted  and  other  products  generated  by  SS/HH  in  this  phase 
include: 
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Exhibit  D-17.  SS/HH  in  the  Requirements  Definition  Phase 


o 

Q 

© 

Q 

or 


CO 

I 

CD 

S' 

O 

TJ 

C 

CO 

CO 

c 

g 

5 

I 

X 

X 

co 

co 

.12 

is 

CO 

CO 


Q. 

CD 

O 

c 

o 

o 

E 

Q) 

GO 

>s 

CO 


CO 

c 

u. 

TO 

“co 

-C 

o 

CO 

TO 

to 

TO 

-3 

CO 

> 

LU 

co 

1 

o 

CD 

S' 

O 


c 

CO 


CO 


TO 

II 

CD  *5 
3  O 

co  O 
*  X 

2S 

w  CO 


LU 


CD 
T3 
Q. 

D  TJ 
^  0) 
X  X  s 

55  c 
co  co  <!> 
co  co  2 


0. 

co 


LU 

H 

o: 

2 

a 

a 

x 

O 

a 

X 

o 

CL 
CL  ^ 

Is 

W  f  CM 

|  cl 

£  a 
a.  * 

-  CL  "D 
Q-  CO  = 
=  CO  m 


w/ 

X 

o 

i2 

3 


i-  cm  co  ^  in 


od 

c 

CD 

IS 

c 

CD 

E 

3 

a 

o 

•o 

TO 

3 

O 

CO 

c 

o 

o 

© 

-O 

CO 

o 

s. 

CL 

CO 

o 

co  tn 
3  TO 

2  to 

i5 

co  ^ 
co  Q£ 

CO 


© 

© 

a 


c 

o 


© 

O 

© 

c 

© 


CO 

►— 

o 

:d 

D 

O 

X 

X 


CD 

c 

CO 

s 

CO 

E 

to 

a> 


co 

to 


co 

> 


"O 

CD 

3 

C 

IS 

c 

o 

a 

$ 

2 

> 

0) 

h_ 

CO 

o 

CO 


C/D  £ 

*  U. 

CO  ^ 

*  • 


«  03 

t-g 

^  <2 
*o  CO 
is 

CO  CD 
N  ~ 
CO  TO 

x  E 

>*  "O 
m  Q> 
55  CO 

2  O 
C  CL 

i  O 

TO  Q. 

E  TO 

o  3 

*t  TO 
CD  > 

a.  lu 


CO 

a) 

u 

3 

cr 

TO 

>* 

CO 

E 

TO 

£ 

IS 

c 

CD 

E 

CD 


£ 

2  X 
co  7s 
>*  CO 
co  co 

It 

c 

CO  a) 
£  2 


IS 

3 

TO 

E 

2 

3 

CT 

0) 

k» 

c 

5 

TO 

C/3 

^  E 

■o  £ 
c  <0 

■  £ 

S  I 

s  « 
«  E 
§  £ 
E  « 

m  i— 

-D  O 
CO 

CO  c 
CD  o 


CO 

to 

CO 

CO 


jS  ■§ 
>•  § 
8  I 

co  E 

r-  O 
03  g 
CO  .fc- 

TO  X 

Si 

is 

CO  ~ 
CO  C 
To 

£  E 
C  S 

CD  o 
2  Q 


■3  CL 


TO 

TO 


CO 

CO 

TO 

LU 

CO 

CO 

2 

TO 

CL 

CD 


oico^iocdodo)® 


TO 

cn 

co 


c 

o 

3 

co 

o 

a 

x 

LU 

J2 

a 

8 

§ 

o 

3 


CD 

■o 

§ 


<0 

© 

X 

2* 

£ 

« 

© 

E 

© 

>» 

© 


Q 

15 

Z 

iS 


D-47 


a.  PORD/ORD,  PMP,  TEMP,  hardware/software,  RFPs,  and  KDP-2 

b.  SS/HH  strategy  objectives  for  the  AP 

The  SS/HH  domain  tasks  associated  with  this  phase  include: 

a.  FEA  (BCS  review  continued) 

b.  Update  of  the  System  Safety  Program  Plan 

c.  Performing  a  Preliminary  Hazard  Analysis  (PHA)  to  identify  hazards  associated 
with  each  alternative 

d.  Evaluating  all  considered  materiels,  design  features,  maintenance,  servicing, 
operational  concepts,  and  environments  of  the  new  system  that  should  affect 
safety  throughout  the  system  life  cycle 

e.  Highlighting  special  areas  of  safety  considerations,  such  as  system  limitations, 
risks,  and  man-rating  requirements 

f.  Identifying  safety  requirements  that  may  require  a  waiver  during  the  system  life 
cycle 

g.  Identifying  safety  design  analysis,  test,  demonstration,  and  validation 
requirements 

h.  Documenting  the  System  Safety  analyses,  results,  and  recommendations  for  each 
promising  alternative  system  concept 

i.  Preparing  a  summary  report  of  the  results  of  the  SSE  tasks  conducted  during  the 
phase  to  support  the  decision  making  process 

j.  Tailoring  the  SSE  program  for  subsequent  phases  and  including  detailed 
requirements  in  the  appropriate  contractual  documents 

5. 3. 5. 4  Demonstration  and  Validation  Phase.  The  major  SS/HH  domain  objectives  during  this 
phase  is  to  tailor  of  SS/HH  tasks  to  accommodate  the  specific  acquisition.  Procurements  range 
from  extensive  study  and  analyses  through  hardware  development  to  prototype  testing, 
demonstration,  and  validation.  Exhibit  D-19  illustrates  the  HH/SS  domain  inputs,  tasks,  and 
products  associated  with  this  phase. 

The  HSI  documentation  impacted  by  the  SS/HH  domain  in  this  phase  includes: 

a.  SSPP  update 
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b.  SS/HH  domain  inputs  to  HSISMP 

The  program  documentation  impacted  and  the  products  generated  in  this  phase  include: 
a.  SS/HH  domain  inputs  to  KDP-3 


b.  SS/HH  domain  inputs  as  necessary  to  the  mission  functional  analysis  and  system 
cost/effectiveness  analysis 

The  SS/HH  domain  tasks  associated  with  this  phase  include: 

a.  Completing  preparation  or  update  of  the  SSPP 

b.  Establishing  SSE  specifications  for  system  design  and  criteria  and  verifying  that 
these  requirements  have  been  met 

c.  Participating  in  trade-off  studies  to  reflect  the  impact  on  System  Safety 
requirements  and  risk 

d.  Recommending  system  design  changes  based  on  these  studies  to  ensure  optimum 
safety  consistent  with  performance  and  system  requirements 

e.  Completing  preparation  or  update  the  PHA  to  evaluate  the  configuration  to  be 
tested 

f.  Preparing  a  System  Hazard  Analysis  (SHA)  report  of  the  test  configuration 
considering  the  planned  test  environment  and  methods 

g.  Performing  detailed  hazard  analyses  (SHA  or  SSHA)  of  the  design  to  assess  the 
risk  involved  in  test  operation  of  the  system  hardware  and  software 

h.  Recommending  redesign  or  other  corrective  action  based  on  evaluation  of  the 
results  of  safety  tests,  failure  analyses,  and  mishap  investigations 

i.  Performing  operating  and  support  hazard  analyses  of  each  test,  and  reviewing  all 
test  plans  and  procedures.  Ensuring  that  hazards  identified  by  analyses  and  tests 
are  eliminated  or  their  associated  risk  minimized 

j.  Identifying  critical  parts  and  assemblies,  production  techniques,  assembly 
procedures,  facilities,  testing,  and  inspection  requirements  that  may  affect  safety 
and  ensure  that: 
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(1)  Adequate  safety  provisions  are  included  in  the  planning  and  layout  of  the 
production  line 

(2)  Adequate  safety  provisions  are  included  in  inspections,  tests,  procedures, 
and  checklists  for  quality  control  of  the  equipment  being  manufactured 

(3)  Production  and  manufacturing  control  data  contain  required  warnings, 
cautions,  and  special  safety  procedures 

(4)  Testing  and  evaluation  are  performed  on  early  production  hardware  to 
detect  and  correct  safety  deficiencies 

(5)  Minimum  risk  is  involved  in  accepting  and  using  new  design,  materiels, 
and  production  and  test  techniques 

k.  Establishing  analysis,  inspection,  and  test  requirements  for  government  furnished 
equipment  (GFE)  or  contractor-furnished  equipment  to  verify  prior  to  use  that 
applicable  SSE  requirements  are  satisfied 

l.  Reviewing  logistics  support  publications  for  adequate  safety  considerations,  and 
ensuring  the  inclusion  of  applicable  Department  of  Transportation  (DoT), 
Environmental  Protection  Agency  (EPA),  and  Occupational  Safety  and  Health 
Administration  (OSHA)  requirements 

m.  Ensuring  SSE  requirements  are  incorporated  into  the  system  specification/design 

document 

n.  Preparing  summary  report  of  the  results  of  SSE  tasks  conducted  to  support  the 
decision  making  process 

o.  Continuing  to  tailor  the  SSE  program 

5.3.5. 5  Full  Scale  Development  Phase.  The  major  SS/HH  objective  in  this  program  phase  is 
to  finalize  SS/HH  domain  contributions  to  system  design  and  prepare  for  production.  Exhibit 
D-20  illustrates  the  SS/HH  domain  inputs,  tasks,  and  products  associated  with  this  phase. 

The  HSI  documentation  impacted  by  the  SS/HH  domain  in  this  phase  include: 

a.  HSISMP 

b.  SSPP  updated 

The  program  documentation  impacted  and  the  products  generated  in  this  phase  include: 
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SS/HH  domain  inputs  as  required  to  update  all  acquisition  program 
documentation,  system/subsystem  design,  and  KDP-4 


a. 


b.  SS/HH  domain  inputs  as  required  to  the  Operational  Test  Plan,  Operational 
Deployment  Plan,  Engineering  Design  Model,  Prototype 
Developmental/Operational  Test  and  Evaluation 

The  SS/HH  domain  tasks  associated  with  this  phase  include: 

a.  Completing  preparation  or  update  of  the  SSPP 

b.  Reviewing  preliminary  engineering  designs  to  ensure  safety  design  requirements 
are  incorporated  and  hazards  identified  are  eliminated  or  reduced  to  an  acceptable 
level 

c.  Reviewing  appropriate  engineering  documentation  to  ensure  safety  considerations 
have  been  incorporated 

d.  Identifying,  evaluating,  and  providing  safety  considerations  for  trade-off  studies 

e.  Performing  or  updating  the  SSHA,  SHA,  Operating  and  Support  Hazard  Analysis 
(O&SHA),  and  safety  studies  concurrent  with  the  design/test  effort  to  identify 
design  and/or  operating  and  support  hazards.  Recommend  any  required  design 
changes  and  control  procedures 

f.  Performing  an  O&SHA  for  each  test,  and  reviewing  all  test  plans  and  procedures 

g.  Participating  in  technical  design  and  program  reviews  and  presenting  the  SHA, 
SSHA,  and/or  O&SHA 

h.  Recommending  redesign  or  other  corrective  actions  based  on  identification  and 
evaluation  of  the  effects  of  storage,  shelf-life,  failure  analyses,  and  mishap 
investigations 

i.  Reviewing  logistic  support  publications  for  adequate  safety  considerations  and 
ensuring  the  inclusion  of  applicable  DoT,  EPA,  and  O&SHA  requirements 

j.  Verifying  the  adequacy  of  safety  and  warning  devices,  life  support  equipment, 
and  personal  protective  equipment 

k.  Identifying  the  need  for  safety  training  and  providing  safety  inputs  to  training 
courses 
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l.  Providing  System  Safety  surveillance  and  support  of  test  unit  production  and 
planning  for  production  and  employment.  Identifying  critical  parts  and 
assemblies,  production  techniques,  assembly  procedures,  facilities,  testing,  and 
inspection  requirements  that  may  affect  safety  and  ensuring  that: 

(1)  Adequate  safety  provisions  are  included  in  the  planning  and  layout  of  the 
production  line. 

(2)  Adequate  safety  provisions  are  included  in  inspections,  tests,  procedures, 
and  checklists  for  quality  control  of  the  equipment  being  manufactured. 

(3)  Production  and  manufacturing  control  data  contain  required  warnings, 
cautions,  and  special  safety  procedures. 

(4)  Testing  and  evaluation  are  performed  on  early  production  hardware  to 
detect  and  correct  safety  deficiencies. 

(5)  Minimum  risk  is  involved  in  accepting  and  using  new  design,  materiels, 
and  production  and  test  techniques. 

m.  Ensuring  that  procedures  developed  for  system  test,  maintenance,  operation,  and 
servicing  provide  for  safe  disposal  of  expendable  hazardous  materiel 

n.  Updating  SSE  requirements  in  system  specification/design  documents 

o.  Preparing  a  summary  report  of  the  results  of  the  SSE  tasks  to  support  the  decision 
making  process 

p.  Tailoring  SSE  program  requirements  for  the  Production  and  Deployment  Phase 

5. 3.5. 6  Production  Phase.  The  major  SS/HH  domain  objective  in  this  phase  is  to  address  any 
design  changes  affecting  System  Safety  or  Health  Hazard  control  that  involve  SS/HH  domain- 
related  tasks  in  the  conceptual,  validation,  or  full-scale  engineering  development  phases.  Exhibit 
D-21  illustrates  the  SS/HH  domain  inputs,  tasks,  and  products  associated  with  this  phase. 


The  program  documentation  impacted  or  products  generated  by  the  SS/HH  domain  in  this  phase 
include  SS/HH  domain  inputs  as  required  to  production  RFPs,  system  acceptance  testing,  First 
Article  Developmental/Operational  Test  and  Evaluation,  ILSP  update,  OLSP,  and  Operational 
Baseline  Configuration  Index. 

The  SS/HH  domain  tasks  associated  with  this  phase  include: 
a.  Completing  preparation  or  updating  the  SSPP 
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b.  Identifying  critical  parts  and  assemblies,  production  techniques,  assembly 
procedures,  facilities,  testing,  and  inspection  requirements  that  may  affect  safety 
and  ensuring  that: 

(1)  Adequate  safety  provisions  are  included  in  the  planning  and  layout  of  the 
production  line. 

(2)  Adequate  safety  provisions  are  included  in  inspections,  tests,  procedures, 
and  checklists  for  quality  control  of  the  equipment  being  manufactured. 

(3)  Production  and  manufacturing  control  data  contain  required  warnings, 
cautions,  and  special  safety  procedures. 

(4)  Testing  and  evaluation  are  performed  on  early  production  hardware  to 
detect  and  correct  safety  deficiencies. 

(5)  Minimum  risk  is  involved  in  accepting  and  using  new  design,  materiels, 
and  production  and  test  techniques. 

c.  Verifying  that  test  and  evaluation  are  performed  on  early  production  hardware  to 
detect  and  correct  safety  deficiencies 

d.  Reviewing  all  test  plans  and  procedures.  Ensuring  that  hazards  identified  by  test 
and  analysis  are  eliminated  or  associated  risk  reduced  to  an  acceptable  level 

e.  Reviewing  technical  data  for  warnings,  cautions,  and  special  procedures  identified 
as  required  by  O&SHA  for  safe  operation,  maintenance,  servicing,  storage, 
packaging,  handling,  and  transportation 

5. 3. 5. 7  Deployment  Phase.  The  major  SS/HH  domain  objective  in  this  phase  is  to  identify  the 
SS/HH  lessons  learned  and  to  update  the  lessons-leamed  data  base  for  reference  during  future 
acquisitions.  Exhibit  D-22  illustrates  the  SS/HH  domain  inputs,  tasks,  and  products  associated 
with  this  phase. 

The  HSI  documentation  impacted  by  SS/HH  in  the  phase  includes: 

a.  HSISMP 

b.  SS/HH  domain  inputs  into  lessons-leamed  data  base 

The  program  documentation  impacted  or  products  generated  by  the  SS/HH  domain  in  this  phase 
include  SS/HH  domain  updates  as  required  to  the  ILSP  and  OLSP,  ILS  Effectiveness 
Assessment,  and  Project  Transition  Plan. 
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The  SS/HH  tasks  associated  with  this  phase  include: 

a.  Reviewing  procedures  and  monitoring  results  of  periodic  field  inspections  to 
ensure  acceptable  levels  of  safety  are  maintained.  Identifying  major  or  critical 
characteristics  of  safety  significant  items  that  deteriorate  with  age,  environmental 
conditions,  or  other  factors. 

b.  Reviewing  all  deployment  plans  and  procedures.  Ensuring  that  hazards  identified 
by  analysis  are  eliminated  or  associated  risk  reduced  to  an  acceptable  level. 

c.  Performing  or  updating  hazard  analyses  to  identify  new  hazards  that  may  result 
from  design  changes.  Ensuring  that  safety  implications  of  the  changes  are 
considered  in  all  configuration  control  plans. 

d.  Evaluating  results  of  failure  analyses  and  mishap  investigations.  Recommending 
corrective  actions. 

e.  Monitoring  the  system  throughout  the  life  cycle  to  determine  the  adequacy  of  the 
design  and  operating/maintenance/emergency  procedures. 

f.  Conducting  a  safety  review  of  proposed  new  operating  and  maintenance 
procedures,  or  changes,  to  ensure  the  procedures,  warnings,  and  cautions  are 
adequate  and  inherent  safety  is  not  degraded. 

g.  Documenting  hazardous  conditions  and  system  deficiencies  for  development  of 
follow-on  requirements  for  modified  or  new  systems. 

h.  Updating  safety  documentation  to  reflect  safety  lessons  learned. 

i.  Evaluating  the  adequacy  of  safety  and  warning  devices,  life  support  equipment, 
and  personal  protective  equipment. 

5.4  Manpower.  Personnel,  and  Training  Domains. 

5.4.1  Introduction.  In  describing  the  recommended  model  for  the  life-cycle  management 
domains  of  HSI,  OGDEN  has  tailored  a  unique  set  of  MPT  action  steps  to  the  seven  phases  of 
the  Coast  Guard  acquisition  process.  This  application  has  resulted  in  a  new  methodology  we 
have  coined  MAPTIDES ,  which  stands  for  Manpower,  Personnel  and  Training  Integration  in  the 
Design  of  Systems.  See  Exhibit  D-8  for  an  overview  of  the  HSI  process  and  how  MAPTIDES 
integrates  with  other  major  HSI  elements.  MAPTIDES  is  a  subset  of  the  HSI  process  and  a 
unique  Coast  Guard  methodology  designed  to  fully  describe  all  actions  required  to  determine 
MPT  acquisition  and  life-cycle  requirements  related  to  the  design,  development,  and  support  of 
new  materiel  systems. 
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The  MAPTIDES  Methodology  has  three  specific  applications  depending  on  the  type  of  materiel 


procured: 

a. 

Equipment/System/Subsystem  (E/S/S)  Application 

b. 

Aviation  Application 

c. 

Total  Vessel  Application. 

Each  application  has  a  five-action-step  process  that  describes  specifically  how  to  determine  MPT 
requirements  in  each  case.  The  E/S/S  and  Aviation  Applications  use  the  same  five  steps,  while 
the  Total  Vessel  Application  uses  a  distinctly  different  five-step  process. 

When  the  MAPTIDES  Methodology  is  used  in  the  Aviation  Application,  it  encompasses  MPT 
requirements  for  aircraft  and  any  other  aviation  equipment  (i.e.,  aviation  E/S/S)  procured 
through  the  Coast  Guard  acquisition  system.  The  Total  Vessel  Application  of  MAPTIDES 
applies  MPT  requirements  related  only  to  the  vessel  and  its  support.  The  E/S/S  Application 
covers  all  remaining  systems  procured  through  the  Coast  Guard  acquisition  process  (e.g., 
LORAN  equipment  and  radars  for  shore  installations). 

The  MAPTIDES  Methodology  is  sequenced  to  develop  manpower  and  personnel  quality 
requirements  first  and  to  use  those  requirements  as  inputs  in  developing  the  Coast  Guard 
Training  Plan  (CGTP).  The  CGTP  displays  all  Manpower,  Personnel,  and  Training  domain 
requirements  for  the  new  acquisition.  The  following  paragraphs  will  describe  the  MAPTIDES 
Methodology  for  determining  MPT  domain  requirements  in  each  application.  Once  the 
methodology  is  described,  we  will  present  the  timing  required  by  integrating  the  MAPTIDES 
Methodology  into  the  Coast  Guard’s  seven-phase  acquisition  process. 

5.4.2  Manpower  Domain.  Manpower  is  the  human  resource  requirements  and  authorizations 
(i.e.,  military  billets  and  civilian  positions)  needed  for  the  operation,  maintenance,  and  support 
of  each  new  materiel  system,  including  both  billet/position  quantity  and  quality  (quality  refers 
to  occupational  specialty,  pay  grade,  and  special  skill  requirements).  This  domain  requires  an 
evaluation  of  the  manpower  changes  generated  by  each  proposed  new  system,  comparing  the 
new  manpower  needs  with  those  of  any  older  system(s)  being  replaced,  and  an  assessment  of 
the  impact  of  the  changes  on  the  total  manpower  limits  of  the  Coast  Guard.  If,  given  manpower 
priorities  established  by  the  Coast  Guard  Headquarters,  materiel  systems  cannot  be  supported 
by  projected  manpower  resources,  then  changes  in  system  design,  organization,  or  doctrine  must 
be  made  to  achieve  affordability.  In  the  materiel  acquisition  process,  manpower  analysis  and 
actions  are  necessarily  conducted  in  conjunction  with  Coast  Guard  force  structure  and  budget 
processes. 

The  Coast  Guard  maintains  a  personnel  classification  system  that  defines  the  various  career  fields 
performing  the  work  required  to  meet  manpower  requirements.  In  determining  the  quality 
associated  with  new  billets/positions,  the  manpower  analyst  should  refer  to  the  classification 
system  a  guide  for  standardization.  The  classification  system  is  a  direct  link  between  the 
manpower  and  personnel  domains. 
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The  primary  factors  that  determine  manpower  costs  are  the  number,  complexity,  and  frequency 
of  tasks  that  require  operators,  maintained,  and  support  personnel.  These  factors  determine  the 
quantity  of  personnel  required,  aptitude  levels,  experience,  and  degree  of  specialized  training 
required  of  individuals  to  perform  each  task.  As  a  result,  billets/positions  drive  the  number  and 
quality  of  personnel  required  to  meet  Coast  Guard  requirements. 

Manpower  planning  is  by  no  means  an  "exact  science.”  There  is  no  single,  absolute  relationship 
between  hardware  and  manpower.  The  operational  scenario  and  maintenance  concept  are 
primary  drivers  of  most  Coast  Guard  manpower  requirements.  For  vessels  the  size  of  cutters, 
the  watch  station  requirements  are  the  principal  manpower  driver.  Increased  system  utilization 
means  increased  maintenance  requirements  for  a  fixed  hardware  design.  The  quantitative 
requirements  are  sensitive  to  the  qualitative  attributes  of  assigned  personnel  (e.g.,  three 
personnel  at  paygrade  E-6  may  perform  the  same  workload  as  four  individuals  at  paygrade  E-5 
because  of  the  increased  skill  level).  Policy  decisions  such  as  continuous  manning  and  key 
personnel  redundancy  may  also  create  manpower  requirements  not  directly  related  to  the  design 
of  equipment. 

The  manpower  planning  process  includes  the  forecasting  of  manpower  requirements  and 
personnel  availability,  as  well  as  the  development  of  alternative  policies,  in  order  to  resolve 
remaining  discrepancies.  In  principle,  a  match  of  manpower  requirements  and  personnel 
availability  can  be  obtained  not  only  by  adapting  either  the  requirement  or  the  availability,  but 
also  by  adapting  a  mix  of  both.  The  MAPTTDES  Methodology,  which  incorporates  the  MPT 
requirements  determination  processes,  trade-off  analyses,  and  Coast  Guard- wide  MPT 
supportability  assessments,  is  at  the  focal  point  of  this  matching  process. 

5-4.2. 1  Manpower  Analyses  Required.  The  Manpower  Domain  requires  iterative  analyses  as 
an  integral  part  of  the  new  system  design  process,  starting  early  in  the  Program  Initiation  Phase. 

a.  By  selecting  a  Baseline  Comparison  System  as  an  initial  step  (and  before 
conducting  a  complete  BCS  analysis),  the  known  manpower  requirements  of  the 
old  system  can  be  used  to  make  a  rough  Initial  Estimate  of  Manpower 
requirements  for  the  new  system.  See  Appendix  H  for  IEM  format.  This 
estimate  will  be  sufficient  to  start  the  personnel  and  training  analysis  and  for 
planning  until  a  more  complete  BCS  analysis  can  be  done.  "Best  available" 
information  will  be  used  in  each  iterative  analysis  as  the  system  design  matures. 

b.  A  Target  Audience  Description  is  developed  from  the  IEM  based  on  the  Coast 
Guard  occupations,  officer  specialties,  and  similar  civilian  career  fields/pay  plans 
required  for  the  new  procurement.  The  primary  purpose  of  the  TAD  is  to 
provide  human  design  criteria  for  the  hardware/software  contractor  who  will 
design  and  build  the  new  acquisition.  The  TAD  provides  an  official  statement  of 
the  capabilities  and  limitations  of  personnel  expected  to  man  the  new  procurement 
when  fielded.  The  contractor  must  meet  this  criteria  when  designing  and 
developing  the  new  acquisition.  The  TAD  should  be  updated  as  information  is 
refined. 
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The  TAD  delineates  the  quantity  and  quality  of  active  and  reserve  military,  civil 
servants,  and  contractors  who  will  most  likely  operate,  maintain,  and  support  the 
new  procurement  when  fielded.  This  document  describes  the  range  of  individual 
qualifications  on  all  relevant  physical,  mental,  physiological,  biographical,  and 
motivational  dimensions.  The  TAD  relates  these  characteristics  to  the  ability  of 
the  human  to  accomplish  tasks  associated  with  the  operation,  maintenance,  and 
support  of  the  system.  Early  identification  of  these  HSI  concerns  increases  the 
flexibility  available  to  resolve  the  issues  in  terms  of  design,  affordability,  and 
supportability.  The  manpower  portion  of  the  TAD  includes  the  following. 

(1)  Number  authorized/assigned  by  paygrade  for  military/civilian 

(2)  Number  authorized  CONUS/OCONUS  by  paygrade 

c.  The  Front-End  Analysis  commences  as  soon  as  practical  after  the  Project 
Initiation  Phase  begins.  See  Exhibit  D-23  for  a  description  of  FEA.  The  Front- 
End  Analysis  calls  for  a  complete  side-by-side  systems  analysis  of  the  BCS,  and 
will  develop  initial  HSI  requirements,  including  manpower  constraints  and 
limitations,  objectives,  trade-offs,  risks,  and  cost  drivers.  The  results  of  the 
analysis  will  be  used  to  update  the  IEM  and  to  provide  inputs  to  the  major 
program  documentation  (e.g.,  MNS,  AP,  PORD/ORD,  PMP,  TEMP,  and  ILSP). 

d.  Analysis  of  each  system  design  alternative  considered  is  required  to  determine  the 
Manpower  requirements  of  each  alternative  to  be  used  in  the  concept  selection 
decision.  From  an  HSI  perspective  (and  there  may  be  other  considerations  as 
well),  the  alternative  should  be  selected  that  offers  the  best  combination  (i.e.,  best 
value  to  the  Coast  Guard)  of  high  system  performance,  low  human  ability 
requirements  (i.e.,  number  of  people,  aptitudes,  mental  group,  and  training 
burden),  and  low  life-cycle  costs. 

e.  The  MAPTIDES  Methodology  commences  with  data  collection  at  the  same  time 
as  the  Front-End  Analysis.  Both  MAPTIDES  and  Front-End  Analyses  are 
conducted  by  the  office  responsible  for  the  HSI  Program.  See  Exhibit  D-24  for 
a  description  of  the  MAPTIDES  Methodology.  MAPTIDES  and  the  FEA 
continue  in  parallel.  While  the  FEA  determines  HSI  constraints,  objectives,  etc., 
that  will  become  inputs  to  the  major  program  documentation,  MAPTIDES 
provides  the  detailed  procedures  for  conducting  the  BCS  analysis  (thereby  also 
contributing  to  the  development  of  information  provided  as  inputs  to  major 
program  documents)  and  the  remaining  processes  necessary  to  determine  life- 
cycle  Manpower  requirements  for  the  new  system. 

When  the  ILS  Manager  is  assigned  to  the  PM  staff  in  the  Concepts  Exploration 
Phase,  OHSIP  hands-off  the  information  developed  in  the  Front-End  Analysis,  the 
IEM,  and  any  other  data  available  that  would  assist  the  ILS  Manager  in 
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FRONT-END  ANALYSIS 


CD 

>> 

O 

c 

Q> 

3 

CT 

0 


C 

o 

CO 

CO 


CD 

c 

CD 

O 

CO 

c 

0) 

E 

_o 

CL 

0 

x> 


0) 

E 

3 

8 

Q 

I 

>S 

*3 

3 

55 

0 

CO 

3 


jo 

3 

O. 


CL 

£ 

*3  <n 

s  $ 
0^ 


8 


.g>*f 

-c.  E 
o 

*3 


0) 

E 

c 

2 

*> 

c 

03 

TO 

c 

.o 

Id 

k. 

0 

Q_ 

O 


-Q 

TO 

k- 

E 

Q. 

3 

CO 

CO 

0 

"3 

I 

Q. 

“3 

c 

TO 

JO 

c 

*TO 


*2  - 

■3  CO 

0  ~ 

g 
*> 
k. 

0 
CO 

c 

O 

I 

3 


8 

C 

.03 

CO 

0 

■O 

CO 

0 

c 

u= 

0 

Q 


c 

o 

TO 

N 

3 

TO 

*3 

C 

TO 

55 

E 

0 

0 

CO 

k_ 

o 

Cl 

CL 

3 

CO 

■3 

C 

TO 

0* 

k. 

TO 


8  a 
S  2 

>E 

C  £ 

03 

E  - 

O  (0 

Is 

£  CO 
co  Q> 

0  £ 

p)  ^ 

£  8 

c  8 

Is 

(6  « 

2  w 
o 
u 

.2w  . 

tj  o  S 

0)  3?  TO 

ror  E 

£  ®  •§ 

"S  D  ® 

|F*2 

Q.  CL  nj 
Cl<  ‘C 

o^o 

a>  i —  a> 
o  o 

0-2  TO 

o  UJ  E 


>* 

8> 


CO  ® 

m  £ 

CO 


s€ 


& 


cL  « 


*  I 


o 

CO 

0* 

k. 

TO 

£ 

■E 

TO 

X 

c 

o 

‘co 

CO 


o  0  vw 

(D  ^ 

>  -o  £ 

Q)  c  0 

O  TO  •_= 

I 


a 

0 


.  -x  ^ 
.2  -gs 
2  ~  o 
—  c  - 

TO  0  CO 

<% 

>  o 

'■s'0. 

m  CO 
TO  u- 

a  0  co 

E-E.1 


c 

o 

TO 


TO 


▼-  CM 


CO 

.TO 


CO 

.TO 


O  -q 

o  «§ 

co  S2 

:|i 


E 

0 

0? 

>s 

CO 

§ 

c 


0 

CO 

3 

_© 

JO 

CO 

CO 

a 

k. 

£ 

CO 

0 

-c 

u 

TO 

2 

CL 

CL 

CD 

C 

.03 

CO 

0 

“3 


0-3  5  2 


CD 

& 


o 

jb 

TO 

CO 

"3 

C 

TO  ^ 
CO  co 
c  c 

II 

|  E 

E  ° 
>  2 
"3  ^ 
TO  O 

8  .2 
TO 
3 
O  TO 

E  S 

sE 

CO  « 
®  co" 
03 


8> 


i  8* 


.0 


CO 
O  -3 

c  c 

C  0 

®  E 

E 

o 

2 

^  w 
0  “3 
TO  C 
H  TO 


0 

CL 

8 

C 

8 

TO 

C 

O 


& 


*3 

C 

TO 

C 

,g> 

*0 

0 

*3 

! 

TO 

C 

0 

CO 

*5 

8 

«*—* 

0 

*C 

0 

o 

TO  JO 
TO  C 

r  « 
|8 
CO  O 

2  S 

TO  3 

3  0 


CO  0 
>  0 
UJ  c^ 


0 


0 

3 


I  i 

I* 

c  u 

2.®  co 

k_  «Q 

a? 

of 

>s  0 

“  *3 


2  ”3 
o  c 

TO  TO 
LL 

t-  0 
&2 
0 

®  0 
O  0 

"3  _C 
0 

TO  ■§ 

£  ■ 

.  « 
». « 
••s  o 

r=  O) 
X3  . 

a  8 

|8 
"*  S' 
o 

E  c 

f -S 

•s  ~ 

S2- 

!§■ 

Q.  0 

w  S 

c 

W  £ 


< 

LU 


0 

J 

O 

0 

S' 

o 

k. 

o 

‘S' 

2 


i 

i5 

Q. 

fc 

(O' 

E 

0 

£ 

O 

JO 

3 

CL 

0 

TO 

C 

CD 

E 

o 

*3 

JZ 

o 

TO 

0 

C 

TO 

*C 

0 


0 

o 

c 

TO 

E 

ik 

'c 

0 

CL 

*3 

C 

TO 

0“ 

j 

75 

0 

S' 

o 


-Q 

JD 

k. 

O  c 

a 

3  0 

c  E 
o  0 

*5  w 
2  >s 
•  0 

.E  0 
—  £ 
2  0 
.2  §> 

fii 

0  r, 

si 

O  35 

o5  § 

II 

•-  Q) 


0  3 
*5  O 

0  o 

Q  -3 


< 

CO 


*3 

0 

*3 

c r 
0 


2 

CL 

E 

o 

u 

2 

TO 


O 

CD 


0 

0 

TO 

■C 

CL 

c 

o 

TO 

k. 

o 

CL 

X 

LU 

0 


CL 

0 

O 

C 

o 

O 


•!2 
0  Q) 
TO  ■*- 

C  -o 

2  C 
2  CD 


0  TO 

£  c 
0 


E  c  ®  c 

EE  -3  E 


§8 

a  -3 

CM* 


D-fi? 


MAPTIDES  --  MPT  REQUIREMENTS  DETERMINATION  Life-Cycle 

Support 


co  5 
co  r? 

£  O 

L.  •» 

CO  CD 

III 

ill. 


CD  |2> 


2  ° 

u3  g 

i  I 

!  I 


2  Q 
P  2 


co  h- 

S  CL 

c  5 


O  o> 
+—>  c 

CO  F 
CO 

o  2 
O  £ 


CO 

jS 

CO  CO 

S.S 
1  1 


1 

CL 

o 

o 

3 

CM  O 
,  3 

C 

•?! 

T  & 

in 

u. 

CL 

O 

Q. 

Q) 
*— * 

Q) 

O 

T3 

C 

o 

0.1 

Q2  o 

Q.  CD 
oj  -g 

f  | 

Q. 

0> 

2 

a) 

CO 

o 

O 

w  o 

co  Q 

W  O 

53 

a 

t/5  o 

>>  <i= 

w  c  5 
®  o  -M 

S  Sg  CD 

•5  I  E 

t»s 

O  £  TO 

9“  3  c 

a.  o  05 
3  0- 

CO  -o  CO 

^  E  'o 

£  £  -g 

y  g> « 

i  g  a, 

—  Ol 

fc-  V-  ° 
O  O  CO 

co  9  § 

si® 

fif 

•==  "C  0> 


CO 

is  1 

>,  < 
1 1 
I  « 

2?  w 

-  i  ts 
•  ts  = 

c 

2  o  o 
COOO 


*?  g. 

Q.  $ 
Q>  $ 
W  O 


T  & 


D-63 


"  & 
Q.  S> 

0>  m 


“  q3 
C  E 
m  O 

®  ‘53 


.9- Q.  t 
r  o  c) 

52  g  c 

f  is 

°  i> 

tr  w  s£ 
2  ■§  ® 

III 

$  s  f 

l1  CO 

Q.  0  LU 


v  CM  CO 


completing  the  remaining  ILS  tasks.  This  hand-off  initiates  the  interface  required 
between  the  HSI  Program  and  the  ELS  process. 

(1)  While  MAPTIDES  is  working  to  achieve  the  objectives  noted  in  Exhibit 
D-24,  the  ILS  Manager  will  be  taking  a  series  of  actions,  among  others, 
in  executing  the  ILSP  to  cause  the  hardware  contractor  to  develop 
appropriate  deliverables  in  the  following  maintenance-related  areas. 

(a)  Repair  Parts 

(b)  Technical  Manuals 

(c)  Maintenance  Training  Course  Documentation  (i.e.,  Course 
Curriculum) 

(d)  Tools  and  Test  Equipment. 

(2)  Even  though  MAPTIDES  does  not  duplicate  these  areas,  there  is  interface 
coordination  required  from  time-to-time  in  sharing  Manpower  data  to 
ensure  that  both  the  OHSIP  and  ILS  Manager  are  using  the  latest 
information  and  neither  is  duplicating  effort. 

5. 4. 2. 2  MAPTIDES  Documentation.  The  MAPTIDES  Methodology  continues  through  the 
five-action-step  process  during  the  Concepts  Exploration  and  Demonstration/Validation  Phases 
(and  updates  in  the  remaining  phases)  to  produce  the  following  Manpower  documentation. 

a.  For  Aviation  and  E/S/S  Procurements,  the  following  Manpower  documentation 
is  developed: 

(1)  MPT  Concept  Document  (MPTCD)  —  This  document  contains  manpower 
and  maintenance  concepts  derived  from  the  quantitative  manpower 
resource  requirements  (i.e.,  number  of  required  operators,  maintainers, 
and  other  non-training  manpower)  for  each  configuration  of  the  new 
system.  See  Appendix  I  for  format.  The  following  products  are 
developed  in  producing  the  MPTCD: 

(a)  Installation  Schedule 

(b)  Transitioning  Activity  Stand-Up,  Phase-Out  Schedule 

(c)  Other  Manpower  Requirements 
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The  concept  document  is  based  on  a  single  unit  of  the  system  and  is  the 
conceptual  basis  for  developing  the  aggregate  manpower  requirements 
displayed  in  the  MPT  Resource  Requirements  Document. 

(2)  MPT  Resource  Requirements  Document  (MPTRRD)  —  This  document 
details  the  aggregate  quantitative  and  qualitative  billets/positions  and  costs 
that  are  driven  by  the  Manpower  concept.  The  document  displays  MPT 
billets/positions  and  costs  by  fiscal  year  until  the  system  is  totally 
deployed.  Both  the  MPTCD  and  MPTRRD  are  iterative  processes. 
These  processes  are  dynamic  enough  that  the  documents  should  indicate 
the  point  in  the  acquisition  process  when  they  were  prepared.  Products 
developed  in  producing  the  MPTRRD  include  the  following: 

(a)  Coast  Guard-Wide  Organizational  Manpower  Requirements 

(b)  Coast  Guard-Wide  Intermediate  Maintenance  Activity  Support 
Requirements 

(c)  Other  Support  (Non-Training)  Manpower  Requirements 

(d)  Student  Billet  Requirements 

(e)  Instructor  Billet  Requirements 

(f)  Staff  Support  Billet  Requirements 

(3)  Preliminary  Aircraft  Manpower  Document  (PAMD)  —  This  document  is 
prepared  for  aircraft  procurements  only,  and  is  a  statement  of  total 
manpower  required  to  support  the  entire  buy  of  aircraft  by  fiscal  year, 
including  flight  crews,  administrative  support,  and  maintenance  support 
at  the  organizational,  intermediate,  and  depot  level  depending  on  the 
maintenance  concept.  The  PAMD  should  be  developed  by  the  OHSIP, 
reviewed  by  the  Program  Sponsor,  PM,  and  the  Office  of  P,  and  approved 
by  the  Chief  of  Staff  (G-CPA).  The  approved  PAMD  should  be  used  to 
initially  man  the  new  aircraft  organization  and  its  support.  After 
operating  with  this  document  for  about  2  years,  it  should  be  reviewed, 
updated,  and  promulgated  as  an  Aircraft  Manpower  Document  (AMD). 

b.  In  vessel  acquisitions,  the  following  Manpower  documentation  is  developed: 

(1)  Preliminary  Manpower  Report  (PMR)  —  This  report  will  update  the  IEM 
and  contains  a  description  of  the  new  vessel,  an  explanation  and 
justification  of  the  Baseline  Comparison  Model  (BCM),  an  estimate  of 
new  vessel  manpower  requirements,  and  probable  program  trade-offs  (i.e., 
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equipment  options  for  the  new  vessel).  The  manpower  estimate  should  be 
in  the  format  described  in  Appendix  H. 

(2)  Preliminary  Vessel  Manpower  Document  (PVMD)  —  The  PVMD  can  be 
developed  using  the  Navy  Manpower  Requirements  System  (NMRS) 
Model,  or  by  contractor.  The  Coast  Guard  is  currently  using  this  model 
to  produce  Manpower  Documents  for  existing  Coast  Guard  Cutters. 
Appendix  J  includes  the  kind  of  information  that  NMRS  can  provide,  and 
it  shows  the  format  used  to  generate  Ship  Manpower  Documents  (SMDs). 
The  analyst  collects  workload  and  other  specific  data  required  to  run  the 
model  and  produce  the  PVMD.  The  PVMD  will  be  similar  in  format  to 
SMDs,  but  modified  as  necessary  to  account  for  differences  in  manpower 
coding  structure,  organization  of  work  centers,  etc.  Like  the  PAMD,  the 
PVMD  should  be  developed  by  the  OHSIP,  reviewed  by  the  Program 
Sponsor,  PM,  and  the  Office  of  P,  and  approved  by  G-CPA.  After 
operating  with  this  document  for  about  2  years,  it  should  be  reviewed, 
updated,  and  promulgated  as  a  Vessel  Manpower  Document  (VMD). 

5.4. 2. 3  MAPTIDES  Methodology  for  Determining  Manpower  Domain  Requirements.  Analyses 
of  Manpower  requirements  are  completed  in  each  of  two  different  applications  of  the 
MAPTIDES  Methodology  (see  Exhibit  D-24): 

a.  Both  Aviation  and  E/S/S  procurements  share  the  same  application  of  the 

methodology. 

b.  Total  Vessel  acquisitions  use  a  distinctly  different  application. 

5. 4. 2. 3.1  E/S/S  Application.  This  application  is  used  for  all  procurements  acquired  through 
the  Coast  Guard  acquisition  process,  except  for  Aviation  E/S/S  and  vessel  procurements.  Refer 
to  Exhibit  D-25  for  E/S/S  MAPTIDES  MPT  requirements  determination  methodology. 

a.  Step  1.  Collect  Preliminary  Data/Conduct  Systems  Analysis 

(1)  Data  is  collected  and  reviewed  by  the  analyst  on  the  new  E /S/S 
requirements,  concepts,  functions,  performance  goals,  performance 
standards,  and  equipment. 

(2)  A  systems  analysis  is  performed  to  select  a  BCS.  The  BCS  will  be  based 
either  on  the  predecessor  system  or  a  group  of  comparable  existing 
systems  that  best  match  the  new  system  requirements,  concepts, 
performance  standards,  and  equipment.  Billet/position  requirements  data 
are  collected  on  the  platform/activities  where  the  BCS  is  installed. 
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Exhibit  D-25.  E/S/S  and  Aviation  MANTIDES  MPT  Requirements 
Determination  Methodology 
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(3)  Step  1  initiates  development  of  the  application’s  data  base  and  audit  trail 
used  to  track  the  design  effort  throughout  the  remainder  of  the  project. 

b.  Step  2.  Conduct  Comparability  Analysis 

(1)  This  step  consists  of  a  series  of  procedures  to  assess  differences  in 
resource  requirements  between  the  BCS  and  the  new  system.  This  is  done 
by  comparing  known  parameters  of  the  BCS  with  characteristics  and 
performance  standards  of  the  new  E/S/S. 

(2)  A  comparison  is  done  of  both  operator  and  maintainer  functional  tasks 
between  the  BCS  and  new  E/S/S.  This  comparability  analysis  traces  the 
source  of  resource  changes  to  differences  in  requirements,  concepts, 
performance  standards,  and  equipment. 

(3)  Estimates  of  key  Manpower  data  elements  for  new  systems  are  determined 
from  comparable  BCS  values  through  the  formulation  of  deltas.  A  delta 
is  the  estimated  change  in  BCS  values  dictated  by  design,  operational,  and 
functional  changes  in  the  new  system.  See  Appendix  K  for  a  discussion 
of  how  to  determine  deltas. 

c.  Step  3.  Develop  the  Manpower  Concept 

This  step  consists  of  three  substeps  and  results  in  development  of  the  MPT 

Concept  Document. 

(1)  The  configuration(s)  and  installation  schedule  for  the  new  E/S/S  are 
developed.  This  provides  the  analyst  with  the  number  and  types  of 
platforms/activities  where  the  new  E/S/S  will  be  installed,  as  well  as  the 
number  of  installations  by  fiscal  year.  This  information  is  available  from 
the  Program  Sponsor  and  will  be  included  in  the  MNS  and  AP. 

(2)  The  Manpower  concept  is  derived  from  the  quantitative  and  qualitative 
manpower  resource  requirements  for  each  unique  E/S/S  configuration. 
These  requirements  are  grouped  into  three  categories: 

(a)  Maintenance  manpower 

(b)  Operator  manpower 

(c)  Other  non-training  manpower 

(3)  The  Manpower  portion  of  the  MPT  Concept  Document  is  prepared  by  the 
analyst  using  data  from  the  previous  two  substeps.  See  Appendix  I  for 
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MPTCD  format.  This  concept  document  provides  basic  input  to  the  MPT 
Resource  Requirements  Document. 

d.  Step  4.  Develop  Manpower,  Personnel,  and  Training  Resource  Requirements 
Document 

In  Step  3,  the  Manpower  concept  for  operating,  maintaining,  and  supporting  a 
single  E/S/S  configuration  was  determined.  In  Step  4,  Coast  Guard-wide 
Manpower  resource  requirements  are  determined  and  displayed  by  location  and 
by  fiscal  year. 

e.  Step  5.  Develop  Program  Documentation  Input 

(1)  The  MAPTIDES  Methodology  is  a  structured  and  systematic  means  of 
addressing  the  many  Manpower  issues  in  the  Coast  Guard  acquisition 
process.  One  principal  value  of  this  methodology  is  that  it  produces  a 
single  data  source  to  be  used  by  OHSIP  to  meet  all  Manpower 
documentation  requirements,  thus  promoting  consistency  and 
comparability. 

(2)  Manpower  inputs  are  required  in  all  major  program  documentation  and 
should  be  updated  prior  to  each  Key  Decision  Point. 

5.4.2. 3.2  Aviation  Application.  This  application  is  similar  to  the  E/S/S  application.  See 
Exhibit  D-25  for  the  basic  steps  in  this  application.  The  Exhibit  describes  procedures  for 
applying  the  MAPTIDES  Methodology  to  determine  Manpower  requirements  for  aircraft  and 
Aviation  E/S/S  acquisitions.  The  Aviation  Application  is  composed  of  the  following  five  steps 
that  together  provide  a  structure  for  Manpower  planning,  analysis,  and  documentation  during 
the  Coast  Guard  acquisition  process. 

a.  Step  1.  Collect  Preliminary  Data  and  Conduct  Systems  Analysis 

This  step  consists  of  two  substeps.  The  analyst  performs  the  following: 

(1)  Collects  and  reviews  data  on  new  Aviation  E/S/S  requirements,  concepts, 
functions,  performance  goals,  performance  standards,  and  equipment. 

(2)  Conducts  systems  analysis  aimed  at  identifying  a  suitable  BCS. 

Data  from  this  step  are  used  to  initiate  development  of  the  application’s  data  base 
and  audit  trail.  This  data  is  also  used  in  Step  2. 

b.  Step  2.  Conduct  Comparability  Analysis 
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This  step  compares  known  parameters  of  the  BCS  with  those  of  the  new  Aviation 
E/S/S  collected  in  Step  1.  The  objective  is  to  quantify  resource  differences 
between  the  two  E/S/S.  This  is  accomplished  by  comparing  functional  tasks  (both 
operator  and  maintainer)  of  the  BCS  with  the  new  E/S/S.  This  procedure  will 
trace  the  source  of  resource  changes  to  differences  in  requirements,  concepts, 
performance  standards,  or  equipment.  This  assessment  becomes  part  of  the  data 
base,  and  the  resulting  information  is  used  in  the  next  two  steps. 

c.  Step  3.  Develop  the  Manpower  Concept 
This  step  consists  of  two  substeps. 

(1)  An  analyst  develops  the  installation  schedule  for  the  new  Aviation  E/S/S. 
This  schedule  provides  the  analyst  with  information  on  the  number  and 
types  of  platforms/activities  on  which  the  new  E/S/S  will  be  installed,  and 
the  number  of  units  to  be  installed  each  fiscal  year.  Additionally,  for  new 
aircraft  units,  schedules  are  developed  for  the  new  aircraft  unit  stand-up 
and  for  predecessor  unit  phase-out.  The  analyst  will  also  identify  other 
manpower  requirements  from  other  commands  and  activities  tasked  to 
support  the  new  E/S/S,  such  as  manpower  to  support  Development  or 
Operational  Test  and  Evaluation,  Plant  Representatives,  and  staff-level 
support. 

(2)  The  analyst  prepares  the  Manpower  input  to  the  MPTCD.  See  Appendix 
1  for  MPTCD  format.  This  document  is  used  as  input  to  Step  4. 

d.  Step  4.  Develop  Manpower  Resource  Requirements 

(1)  In  this  step,  total  Coast  Guard-wide  Manpower  resource  requirements  are 
determined  and  displayed  by  location  (installation,  maintenance,  and 
training)  and  by  fiscal  year. 

(2)  For  new  aircraft  acquisitions,  total  Coast  Guard-wide  resource 
requirements  are  developed,  first  on  an  aviation-unit  level  and  displayed 
by  fiscal  year.  Additional  Manpower  requirements  generated  as  a  result 
of  the  aggregation  of  aircraft  into  aviation  units  are  also  addressed. 

(3)  Data  developed  in  this  step  are  summarized  into  a  volume  called  the  MPT 
Resource  Requirements  Document.  The  format  for  the  MPTRRD  is  a 
series  of  summary  worksheets  that  roll  up  the  different  categories  of 
manpower  resource  requirements  by  fiscal  year,  with  short  narratives  to 
describe  the  various  categories. 

e.  Step  5.  Develop  Program  Documentation  Input 
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This  step  is  the  same  as  step  5  in  paragraph  5. 4. 2. 3.1  E/S /S  Application. 


5.4. 2. 3. 3  Total  Vessel  Application.  This  application  of  the  MAPTIDES  Methodology  differs 
considerably  from  the  other  applications.  The  Total  Vessel  Application  requires  the  analyst  to 
take  into  account  manpower  cross-utilization,  habitability  constraints,  non-hardware-based 
manpower  requirements  (such  as  watch  stations  and  organizational  support),  and  the  impact  of 
multiple  E/S/S  configurations.  This  application  should  also  make  maximum  use  of  existing 
automated  data  systems  (i.e.,  models)  to  determine  Manpower  domain  requirements. 

Despite  these  differences,  the  Total  Vessel  Application  utilizes  the  same  analytical  principles  and 
techniques,  and  produces  data  comparable  to  the  other  MAPTIDES  applications.  Because  Total 
Vessel  Acquisition  programs  often  involve  procurement  of  multiple  new  hardware  components, 
this  application  is  designed  to  draw  on  the  Aviation  and  E/S/S  Applications  when  those 
components  are  present  on  new  vessels. 

The  Total  Vessel  Application  is  composed  of  the  following  five  action  steps  that  together  provide 
a  structured  approach  to  Manpower  planning  and  analysis  for  vessels.  See  Exhibit  D-26  for  an 
overview  of  the  methodology. 

a.  Step  1.  Collect  Preliminary  Total  Vessel  Data 

(1)  This  step  requires  the  analyst  to  collect  and  analyze  preliminary  program 
data  on  the  new  vessel,  including  mission  constraints,  performance  goals, 
and  planned  equipment. 

(2)  Based  on  data  collected,  the  analyst  will  develop  a  description  of  the  total 
vessel  Manpower  requirements  and  initial  vessel  concept  summaries. 

b.  Step  2.  Conduct  Manpower  Engineering  Study 

Step  2  has  four  substeps  to  determine  the  likelihood  of  the  new  vessel  meeting  its 

mission  requirements  and  its  Manpower  supportability. 

(1)  Using  the  new  vessel’s  equipment  and  mission,  the  analyst  will  describe 
a  notional  vessel  that  will  be  used  to  select  a  Baseline  Comparison  Model. 
The  BCM  will  be  a  complete  vessel  (consisting  of  the  predecessor,  if  there 
is  one,  and  other  systems  similar  to  the  new  vessel),  and  it  will  be  made 
up  of  systems  and  equipment  that  have  established  and  validated 
Manpower  data  approximating  the  requirements  and  constraints  of  the  new 
vessel. 

(2)  The  analyst  may  use  the  BCM  equipment  list  to  formulate  inputs  to  the 
Navy  Enhanced  Manpower  Determination  Model  (EMDM)  or  may 
contract  to  have  this  information  developed.  When  the  Navy  model  is 
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used,  it  is  a  computerized  manpower  estimation  system  consisting  of  a 
series  of  modules  (i.e. ,  work  centers)  that  describe  the  new  vessel.  The 
EMDM  takes  cross-utilization  of  manpower  into  account  to  fully  utilize 
all  available  man-hours. 

(3)  An  initial  estimate  of  manpower  requirements  from  the  model  or  a 
contractor  will  be  used  to  conduct  a  crew  size  feasibility  analysis.  This 
study  will  be  designed  to  determine  whether  the  crew  can  be 
accommodated  and  supported  by  the  proposed  vessel  design.  For 
example,  the  estimated  crew  for  the  new  vessel  may  be  65  billets,  but  the 
designers  may  have  only  provided  space  for  40  people.  In  this  case,  the 
crew  size  is  clearly  not  practical;  either  the  design  of  the  vessel  or  its 
proposed  capabilities  must  be  changed. 

(4)  Based  on  iterations  of  manpower  runs  in  the  EMDM  or  similar 
information  from  a  contractor,  the  analyst  will  prepare  a  Preliminary 
Manpower  Report.  The  following  format  will  be  used. 

(a)  Introduction.  Since  several  iterations  of  the  PMR  may  be 
produced  before  the  Preliminary  Vessel  Manpower  Document  is 
finalized,  the  introduction  should  indicate  in  what  phase  of  the 
acquisition  process  this  particular  PMR  was  completed. 

(b)  New  Vessel  Description.  This  is  a  narrative  describing  major 
features,  equipment,  and  capabilities  of  the  new  vessel  that  drive 
manpower.  If  BGM  equipment  is  used,  it  should  be  clearly 
labeled.  The  analyst  should  also  note  that  not  all  billets  are  driven 
by  equipment.  The  following  sub-elements  are  included: 

1  New  vessel  description 

2  Mission 

2  Requirements/constraints 

4  Known  new  vessel  equipment 

(c)  New  Vessel  Manpower  Requirements.  This  section  will  involve 
a  brief  narrative  of  the  new  vessel’s  manpower  concepts  and  a  list 
of  manpower  estimates. 

(d)  Equipment  Options.  This  is  a  narrative  explanation  of  probable 
equipment  options  and  their  impact  on  manning,  including  quantity 
and  quality,  if  possible. 
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c. 


(e)  Conclusion.  The  analyst  will  summarize  the  manpower 
requirements  of  the  new  vessel  and  discuss  any  other  relevant 
factors  concerning  manpower  associated  with  the  new  vessel. 

(f)  Appendices.  The  analyst  will  provide  the  following  appendices 
and  any  other  information  relevant  to  the  report  that  does  not  fit 
in  the  main  body  of  the  document. 

1  Point  of  Contact  List 

2  Initial  Estimate  of  Manpower  (used  to  run  the  EMDM) 

2  A  discussion  of  crew  size  feasibility 

Step  3.  Determine  Operational  Manpower  Requirements 

(1)  The  Preliminary  Vessel  Manpower  Document  is  developed  during  this 
step.  The  PVMD  displays  the  manpower  requirements  for  a  single  new 
vessel.  This  information  is  then  multiplied  by  the  new  vessel  delivery 
schedule  to  produce  the  manpower  requirements  of  the  entire  new  vessel 
class. 

(2)  Developing  the  PVMD  requires  determination  of  workload  requirements. 
This  may  be  done  through  the  Navy  Manpower  Requirements  System 
Model  or  by  contractor.  If  the  Navy  model  is  used,  the  analyst  develops 
workload-related  input  requirements  and  forwards  them  to  the  Navy  for 
running  the  model.  Workload  is  broken  into  the  following  five  categories: 

(a)  Planned  Maintenance  fPLMl.  PLM  is  work  accomplished  in 
response  to  scheduled  requirements.  It  is  the  total  workload 
associated  with  the  performance  of  maintenance  actions  on 
operational  systems,  equipment,  or  components. 

(b)  Corrective  Maintenance  (CM1.  CM  is  work  accomplished  on  an 
unscheduled  basis  because  of  malfunction,  failure,  or  deterioration. 
It  is  the  workload  associated  with  restoration  of  disabled  systems, 
equipment,  or  components  to  an  operational  condition. 

(c)  Facility  Maintenance  fFMl.  FM  consists  of  maintaining  the 
cleanliness  and  sanitation  of  all  habitable  areas  and  preserving  the 
hull,  decks,  superstructure,  and  equipment  against  corrosion  and 
deterioration. 
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(d)  Own  Unit  Support  (OUS).  OUS  consists  of  the  manpower 
required  to  provide  administrative,  command,  supply,  medical, 
utility  task,  and  special  evolution  support. 

(e)  Watch  Station  Requirements  fWSRl.  WSR  consists  of  the 
manpower  needed  for  essential  operating  stations  as  directed  by  the 
Required  Operational  Capability  (ROC)  during  a  specific  condition 
of  readiness  with  system  scenario  defined  by  its  Projected 
Operating  Environment  (POE).  WSR  is  also  sometimes  referred 
to  as  operational  manning  (OM). 

(3)  If  the  NMRS  model  is  used,  the  analyst  will  provide  workload-related  data 
and  the  Navy  will  produce  the  manpower  portion  of  the  PVMD.  The 
analyst  will  then  add  a  foreword  consisting  of  the  following: 


(a)  Introduction 

(b)  POE 

(c)  ROC  Statement 

(d)  Definition  of  Terms 


See  Appendix  J  for  the  PVMD  format. 

d.  Step  4.  Develop  New  Ship  Training  Requirements 

In  this  step,  the  analyst  will  develop  the  training  requirements  of  the  new  vessel 
and  produce  a  draft  CGTP  using  manpower  estimates  as  a  starting  point. 

e.  Step  5.  Develop  Program  Documentation  Input 

This  step  is  the  same  as  Step  5  of  the  E/S/S  Application,  paragraph  5.4.2.3.I. 

5.4.3  Personnel  Domain.  Personnel  refers  to  the  people  required  to  fill  authorized  billets  and 
positions,  both  quantity  and  quality.  Personnel  includes  the  military  and  civilians  with  the 
aptitudes,  skill  levels,  experience,  and  other  human  physical  and  mental  characteristics  needed 
to  operate,  maintain,  and  support  Coast  Guard  equipment,  vessels,  and  aircraft.  This  domain 
requires  detailed  assessment  of  the  aptitudes,  mental  groups,  and  experience  that  personnel  must 
possess  to  complete  training  and  successfully  use,  operate,  and  maintain  the  system. 

a.  New  systems  must  be  configured  specifically  to  accommodate  the  forecast 
capabilities  of  personnel  projected  to  be  available  when  the  system  is  fielded;  this 
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is  one  of  the  criteria  for  determining  that  the  new  system  is  supportable  from  a 
personnel  standpoint. 

Personnel  analysis  must  consider  not  only  simple  availability,  but  also  the 
capability  of  the  Coast  Guard  personnel  system  to  provide  the  needed  numbers 
of  properly  qualified  people,  at  a  reasonable  cost,  and  in  the  time  frame  required. 
Personnel  should  be  included  in  system  life-cycle  cost  estimates  and  system 
design  trade-offs,  i.e.,  machine  costs  versus  personnel  costs.  Personnel  analyses 
and  projections  are  needed  in  time  to  allow  orderly  recruitment,  training,  and 
assignment  of  personnel  in  conjunction  with  equipment  fielding. 

b.  Personnel  planning  during  systems  acquisition  is  the  process  of  acquiring  the 
human  resources  necessary  to  support  identified  manpower  requirements.  It 
involves  procurement,  classification,  development,  and  utilization  of  personnel. 
Put  simply,  it  is  the  function  of  "matching  faces  to  spaces."  The  Personnel 
Management  System  is  depicted  in  Exhibit  D-27. 

The  personnel  community  has  two  major  roles  to  play  in  the  acquisition  process. 
One  role  is  in  establishing  and  maintaining  a  classification  system;  this  includes 
developing  and  managing  career  fields.  Classification  is  based  on  an  analysis  of 
tasks  necessary  to  support  the  new  system.  A  comparison  of  those  tasks  to 
existing  Coast  Guard  personnel  standards  will  determine  the  occupational 
specialty,  paygrade,  and  special  skill  requirements.  This  should  confirm  the 
manpower  quality  determined  in  the  Initial  Estimate  of  Manpower  using  the 
Baseline  Comparison  System.  Any  differences  should  be  resolved  in  favor  of  the 
quality  determined  by  the  personnel  system  (or  change  the  personnel  standards). 

The  second  role  of  the  personnel  community  during  the  acquisition  process  is  to 
plan  for,  recruit,  classify,  assign,  and  manage  the  people  necessary  to  operate, 
maintain,  and  support  the  new  system.  An  important  function  of  personnel 
planning  is  the  development  of  a  projected  force  structure  designed  by  grade, 
occupational  specialty,  and  years  of  service.  The  projected  force  structure 
represents  an  integration  of  billet  authorizations  and  of  personnel  policies 
necessary  for  effective  and  efficient  force  management. 

The  supportability  assessment  portion  of  the  MAPTIDES  Program  enables  the 
Coast  Guard  to  engage  in  systematic  trade-off  analysis  of  system  alternatives. 
Supportability  data  allows  Coast  Guard  decision  makers  to  view  manpower 
requirements  and  personnel  resources  in  aggregate  form  and  use  this  combined 
data  to  assess  development  options.  Similarly,  aggregated  data  of  Coast  Guard 
personnel  resources  and  requirements  helps  the  Coast  Guard  make  maximum  use 
of  its  available  personnel  by  tailoring  its  system-wide  inventory  to  its  manpower 
resource  base. 


D-76 


Exhibit  D-27.  Personnel  Management  System 
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It  is  crucial  that  the  Coast  Guard  maintain  a  complete,  functional  Personnel 
management  system.  An  important  point,  shown  by  Exhibit  D-27,  is  that  no 
overall  personnel  management  system  exists  until  a  module  or  subsystem  is 
operating  for  each  of  the  functional  personnel  areas  and  all  are  linked  together. 
In  this  way,  the  Coast  Guard  has  the  capability  to  match  personnel  and  job  — 
skill  with  requirement. 

Personnel  availability  in  subsequent  years  depends  on  the  actual  manpower 
distribution  and  the  existing  personnel  policies  (e.g.,  career  paths  and  training 
course  availability),  which  may  be  explicitly  formulated  or  that  may  exist 
implicitly.  Furthermore,  personnel  availability  also  depends  on  external 
variables,  such  as  the  size  of  the  available  labor  force  and  the  labor  market.  The 
values  of  these  variables  determine  personnel  availability,  that  is,  the  number  and 
qualification  of  personnel  expected  to  be  available  to  the  Coast  Guard  in  future 
years. 

The  personnel  community  needs  to  know  the  detailed  manpower  requirements  for 
new  systems  as  early  as  possible  in  the  acquisition  cycle  to  effectively  provide 
Personnel  planning.  Manpower  and  Personnel  are  complementary  disciplines  and 
their  effective  and  efficient  interaction  in  the  acquisition  process,  as  supported  by 
the  HSI  Program,  will  enhance  system  supportability  while  contributing  to  a 
stable  and  productive  force  structure. 

5.4.3. 1  Personnel  Analyses  Required.  The  Personnel  Domain  requires  iterative  analyses  as 

an  integral  part  of  the  new  system  design  process,  starting  early  in  the  Project  Initiation  Phase. 

a.  By  selecting  a  Baseline  Comparison  System  as  an  initial  step  (and  before 
conducting  a  complete  BCS  analysis),  the  known  personnel  requirements  of  the 
old  system  can  be  used  to  make  a  rough  initial  estimate  of  requirements  for  the 
new  system  (i.e.,  the  personnel  quality  associated  with  the  IEM,  including 
occupational  specialty,  paygrade,  and  qualification  code  requirements).  See 
Appendix  H  for  IEM  format. 

b.  When  the  IEM  is  determined,  development  of  a  Target  Audience  Description  is 
initiated  based  on  the  military  occupations,  officer  specialties,  and  similar  civilian 
career  fields/pay  plans  required  for  the  new  procurement.  The  TAD  delineates 
the  quantity  and  quality  of  active  and  reserve  military,  civil  servants,  and 
contractors  who  will  most  likely  operate,  maintain,  and  support  the  new 
procurement.  This  document  describes  the  range  of  individual  qualifications  in 
all  relevant  physical,  mental,  physiological,  biographical,  and  motivational 
dimensions.  This  information  is  included  in  system  hardware/software  requests 
for  proposals,  and  the  selected  contractor(s)  are  held  accountable  for  designing 
the  system  to  these  human  specifications.  The  TAD  is  updated  with  each  new 
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update  of  the  IEM.  Fonnat  for  the  Personnel  portion  of  the  TAD  includes  the 
following: 

(1)  Educational  profiles 

(2)  Reading  grade  levels 

(3)  AFQT  mental  profiles 

(4)  Aptitude  profiles 

(5)  Anthropometric  data 

(6)  Physical  qualifications 

(7)  Biographic  information  on  civilian  education,  gender  mix,  and  percentage 
with  English  as  a  second  language  may  also  be  included. 

c.  The  Front-End  Analysis  commences  as  soon  as  practical  after  start  of  the  Project 
Initation  Phase.  See  Exhibit  D-23  for  a  description  of  the  tasks  that  form  the 
basis  for  FEA.  The  Front-End  Analysis  calls  for  a  complete  side-by-side  systems 
analysis  of  the  BCS,  and  will  develop  initial  HSI  requirements,  including 
personnel  quality,  objectives,  constraints,  trade-offs,  risks,  and  cost  drivers.  The 
results  of  the  analysis  will  be  used  to  provide  inputs  to  the  major  program 
documentation. 

d.  Analysis  of  each  system  design  alternative  considered  is  required  to  determine  the 
Personnel  requirements  of  each  to  be  used  in  the  concept  selection  decision.  The 
objective  from  a  Personnel  Domain  perspective  is  to  evaluate  each  alternative  on 
the  basis  of  how  difficult  that  alternative  will  be  for  the  Personnel  system  to 
execute  in  meeting  the  manpower  (i.e.,  billet/position)  requirements  and  how 
much  impact  that  alterative  will  have  on  the  Personnel  system’s  ability  to  man  the 
remaining  Coast  Guard  manpower  requirements  in  these  same  skills.  For  each 
alterative,  the  evaluation  should  include  relative  requirements  for  numbers  of 
personnel,  education  level,  experience  (i.e.,  pay  grade),  mental  group 
requirements,  etc.  This  analysis  should  be  presented  at  Key  Decision  Point  Two 
in  sufficient  detail  to  describe  the  Personnel  Domain  impact  in  each  concept 
alternative,  including  relative  prioritization  of  the  alternatives  from  the  Personnel 
perspective. 

e.  The  MAPTIDES  Methodology  commences  with  data  collection  at  the  same  time 
as  the  Front-End  Analysis.  See  Exhibit  D-24  for  a  description  of  the  MAPTIDES 
Methodology  and  refer  to  paragraph  5.4.2.  I.e.  for  additional  discussion  of 
MAPTIDES. 
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5. 4. 3. 2  MAPI  IDES  Documentation.  The  MAPTIDES  Methodology  continues  through  the 
five-action-step  process  during  the  Concepts  Exploration  and  Demonstration/Validation  Phases 
(including  updates  in  the  remaining  phases)  to  produce  the  following  Personnel  domain 
documentation. 

a.  For  Aviation  and  E/S/S  procurements,  the  following  documentation  is  developed 
that  requires  Personnel  input: 

(1)  MPT  Concept  Document  (MPTCD)  —  This  document  contains  personnel 
quality  associated  with  the  manpower  and  maintenance  concepts  derived 
from  the  qualitative  Personnel  resource  requirements  (i.e.,  quality  of 
required  operators,  maintained,  and  other  non-training  personnel 
considerations)  for  each  configuration  of  the  new  system.  See  Appendix 
I  for  format. 

The  level  of  detail  presented  should  be  consistent  with  the  level  of 
development  of  the  new  equipment.  For  example,  at  program  initiation 
for  new  technology,  it  may  only  be  appropriate  to  identify  ratings;  at 
KDP-2,  however,  it  should  be  possible  to  identify  ratings,  paygrades,  and 
qualification  codes. 

The  following  products  are  developed  in  producing  the  MPTCD: 

(a)  Installation  Schedule 

(b)  Transitioning  Unit  Stand-Up,  Phase-Out  Schedule 

(c)  Other  Personnel  Requirements 

(2)  MPT  Resource  Requirements  Document  (MPTRRD)  —  This  document 
details  the  aggregate  quantitative  and  qualitative  billets/positions  and  costs 
that  the  Manpower  concept  drives.  Personnel  inventory  constraints  and 
limitations  are  considerations  integral  to  development  of  the  manpower 
requirements  for  a  new  acquisition.  For  example,  if  the  new  system 
requires  an  enlisted  rating  or  special  qualification  that  is  not  currently 
available  in  the  Coast  Guard  inventory,  the  Office  of  P  should  develop  a 
plan  for  establishing  the  new  rating/special  qualification  or  should  propose 
other  alternatives  for  meeting  the  requirement.  The  plan  should  include 
all  the  necessary  elements  to  support  and  sustain  the  new  skill,  including 
the  timeframe  when  the  skill  is  expected  to  be  available  to  the  Coast 
Guard.  The  Personnel  plan  should  be  developed,  approved,  and  included 
in  the  manpower  concept  and  cost  requirements. 
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(3)  Preliminary  Aircraft  Manpower  Document  (PAMD)  —  This  document  is 
prepared  for  aircraft  procurements  only.  It  is  a  statement  of  quantity  and 
quality  of  total  manpower  required  to  support  the  entire  buy  of  aircraft  by 
fiscal  year,  including  flight  crews,  administrative  support,  and 
maintenance  support  at  the  organizational,  intermediate,  and  depot  level 
depending  on  die  maintenance  concept.  Even  though  the  PAMD  is  a 
manpower  document,  the  billet  quality  requirement  should  be  adjusted  as 
required  to  accommodate  the  quality  of  the  personnel  inventory  expected 
to  be  available  to  the  Coast  Guard  when  the  new  system  is  fielded.  The 
manpower  analyst  should  start  with  the  Personnel  descriptions  of  existing 
and  anticipated  enlisted  ratings,  special  qualifications,  and  both  officer 
specialties  and  civilian  career  fields.  These  descriptions  should  include 
aptitude,  mental  group,  education  level,  etc.  required  for  each  category  of 
personnel.  The  analyst  should  use  this  information  in  establishing  the 
manpower  requirements  for  the  new  system. 

b.  In  vessel  acquisitions,  the  following  documentation  is  developed  that  requires 
Personnel  input: 

(1)  Preliminary  Manpower  Report  —  This  report  will  update  the  IEM  and 
contains  a  description  of  the  new  vessel,  an  explanation  and  justification 
of  the  Baseline  Comparison  Model,  an  estimate  of  new  vessel  personnel 
quality  requirements,  and  program  trade-offs  (i.e.,  equipment  options  for 
the  new  vessel).  The  IEW  will  be  in  the  format  described  in  Appendix 
H,  while  the  format  for  the  PMR  is  included  at  paragraph  5.4.2. 3. 3. b. (4). 

(2)  Preliminary  Vessel  Manpower  Document  —  The  PVMD  can  be  developed 
using  the  Navy  NMRS  Model  or  by  contractor.  As  with  similar  Aviation 
and  E/S/S  Manpower  documents,  Personnel  quality  and  support  limitations 
and  constraints  are  primary  considerations  in  developing  the  PVMD. 

5.4.3. 3  MAPTIDES  Methodology  for  Determining  Personnel  Domain  Requirements.  Analyses 
of  Personnel  requirements  are  completed  in  each  of  two  different  applications  of  the  MAPTIDES 
Methodology  (see  Exhibit  D-24). 

a.  Both  Aviation  and  E/S/S  procurements  share  the  same  application  of  the 
methodology. 

b.  Total  Vessel  acquisitions  use  a  distinctly  different  application. 

5.4. 3. 3.1  E/S/S  Application.  This  application  is  used  for  all  procurements  acquired  through 
the  Coast  Guard  acquisition  process,  except  for  aviation  and  vessel  procurements.  Refer  to 
Exhibit  D-25  for  the  specific  steps  included  in  this  application. 
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a.  Step  1.  Collect  Preliminary  Data/Conduct  Systems  Analysis 

(1)  Data  is  collected  and  reviewed  by  the  analyst  on  the  new  E/S/S 
requirements,  concepts,  functions,  performance  goals,  performance 
standards,  and  equipment. 

(2)  A  systems  analysis  is  performed  to  select  a  BCS.  The  BCS  will  be  based 
either  on  the  predecessor  system  or  a  group  of  comparable  existing 
systems  that  best  match  the  new  system  quality  requirements,  concepts, 
performance  standards,  and  equipment.  Personnel  quality  requirements 
data  are  collected  on  the  platform/activities  where  the  BCS  is  installed. 

(3)  Step  1  initiates  development  of  the  application’s  data  base  and  audit  trail 
used  to  track  the  design  effort  throughout  the  remainder  of  the  project. 

b.  Step  2.  Conduct  Comparability  Analysis 

(1)  This  step  consists  of  a  series  of  procedures  to  assess  differences  in 
resource  requirements  between  the  BCS  and  the  new  system.  This  is  done 
by  comparing  known  parameters  of  the  BCS  with  characteristics  and 
performance  standards  of  the  new  E/S/S. 

(2)  A  comparison  is  done  of  both  operator  and  maintainer  functional  tasks 
between  the  BCS  and  new  E/S/S.  This  comparability  analysis  traces  the 
source  of  resource  changes  to  differences  in  requirements,  concepts, 
performance  standards,  and  equipment. 

(3)  Estimates  of  key  Personnel  data  elements  for  new  systems  are  determined 
from  comparable  BCS  values  through  the  formulation  of  deltas.  A  delta 
is  the  estimated  change  in  BCS  values  dictated  by  design,  operational,  and 
functional  changes  in  the  new  system.  See  Appendix  K  for  a  discussion 
of  how  to  determine  deltas. 

c.  Step  3.  Develop  the  Personnel  Concept 

This  step  consists  of  three  substeps  and  results  in  development  of  the  Personnel 

input  to  the  MPT  Concept  Document. 

(1)  The  configuration(s)  and  the  installation  schedule  for  the  new  E/S/S  are 
developed.  This  provides  the  analyst  with  the  number  and  types  of 
platforms/activities  where  the  new  E/S/S  will  be  installed,  as  well  as  the 
number  of  installations  by  fiscal  year.  This  information  is  available  from 
the  Program  Sponsor  and  will  be  included  in  the  MNS  and  AP. 
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(2)  The  Personnel  quality  portion  of  the  MPT  Concept  Document  is  derived 
from  the  qualitative  resource  requirements  for  each  unique  E/S/S 
configuration.  These  requirements  are  grouped  into  three  categories: 

(a)  Maintenance  personnel 

(b)  Operator  personnel 

(c)  Other  non-training  personnel 

(3)  The  Personnel  portion  of  the  MPT  Concept  Document  is  prepared  by  the 
analyst  using  data  from  the  previous  two  substeps.  See  Appendix  I  for 
MPTCD  format.  This  concept  document  provides  basic  input  to  the  MPT 
Resource  Requirements  Document. 

d.  Step  4.  Develop  Manpower,  Personnel,  and  Training  Resource  Requirements 
Document.  In  Step  3,  the  Personnel  quality  portion  of  the  MPT  concept  for 
operating,  maintaining,  and  supporting  a  single  E/S/S  configuration  was 
determined.  In  Step  4,  Coast  Guard- wide  Personnel  resource  requirements  are 
determined  and  displayed  by  location  and  by  fiscal  year. 

e.  Step  5.  Develop  Program  Documentation  Input 

(1)  The  MAPTIDES  Methodology  is  a  structured  and  systematic  means  of 
addressing  the  many  Personnel  issues  in  the  Coast  Guard  acquisition 
process.  One  principal  value  of  this  methodology  is  that  it  produces  a 
single  data  source  to  be  used  by  the  OHSIP  to  meet  all  Personnel 
documentation  requirements,  thus  ensuring  consistency  and  comparability. 

(2)  Personnel  quality  inputs  are  required  in  all  major  program  documentation 
and  should  be  updated  prior  to  each  Key  Decision  Point. 

5. 4.3. 3.2  Aviation  Application.  This  application  is  similar  to  the  E/S/S  application.  See 
Exhibit  D-25  for  the  basic  steps  involved.  It  describes  the  procedures  for  applying  the 
MAPTIDES  Methodology  to  determine  Personnel  requirements  for  aircraft  and  Aviation  E/S/S 
acquisitions.  The  aviation  application  is  composed  of  the  following  five  steps  that  together 
provide  a  structure  for  Personnel  planning,  analysis,  and  documentation  during  the  Coast  Guard 
acquisition  process. 

a.  Step  1.  Collect  Preliminary  Data  and  Conduct  Systems  Analysis 

This  step  consists  of  two  substeps.  The  analyst  performs  the  following  actions: 
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(1)  Collects  and  reviews  data  on  new  Aviation  E/S/S  requirements,  concepts, 
functions,  performance  goals,  performance  standards,  and  equipment 

(2)  Conducts  systems  analysis  aimed  at  identifying  a  suitable  BCS. 

Data  from  this  step  are  used  to  initiate  development  of  the  application’s  data  base 
and  audit  trail.  This  data  is  also  used  in  Step  2. 

b.  Step  2.  Conduct  Comparability  Analysis 

This  step  compares  known  parameters  of  the  BCS  with  those  of  the  new  Aviation 
E/S/S  collected  in  Step  1.  The  objective  is  to  quantify  resource  differences 
between  the  two  E/S/S.  This  is  accomplished  by  comparing  functional  tasks  (both 
operator  and  maintainer)  of  the  BCS  with  the  new  E/S/S.  This  procedure  will 
trace  the  source  of  resource  changes  to  differences  in  requirements,  concepts, 
performance  standards,  or  equipment.  This  assessment  becomes  part  of  the  data 
base,  and  the  resulting  information  is  used  in  the  next  two  steps. 

c.  Step  3.  Develop  the  Personnel  Quality  Portion  of  the  MPT  Concept  Document 
This  step  consists  of  two  substeps. 

(1)  An  analyst  develops  the  installation  schedule  for  the  new  Aviation  E/S/S. 
This  schedule  provides  the  analyst  with  information  on  the  number  and 
types  of  platforms/activities  on  which  the  new  E/S/S  will  be  installed,  and 
the  number  of  units  to  be  installed  each  fiscal  year.  Additionally,  for  new 
aircraft  and  aviation  units,  schedules  are  developed  for  new  unit  stand-up 
and  predecessor  unit  phase-out.  The  analyst  will  also  identify  other 
personnel  requirements  from  other  commands  and  activities  tasked  to 
support  the  new  E/S/S,  such  as  support  for  Development  or  Operational 
Test  and  Evaluation,  Plant  Representatives,  or  staff  level  support. 

(2)  The  analyst  prepares  an  MPT  Concept  Document.  See  Appendix  I  for 
MPTCD  format.  This  document  is  used  as  input  to  Step  4. 

d.  Step  4.  Develop  Personnel  Resource  Requirements 

(1)  In  this  step,  total  Coast  Guard-wide  Personnel  resource  requirements  are 
determined,  which  is  displayed  by  location  (installation,  maintenance,  and 
training)  and  by  fiscal  year. 

(2)  For  new  aircraft  acquisitions,  total  Coast  Guard-wide  resource 
requirements  are  developed,  first  on  an  aviation-unit  level  and  displayed 
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by  fiscal  year.  Additional  Personnel  requirements  generated  as  a  result 
of  the  aggregation  of  aircraft  into  aviation  units  are  addressed. 

(3)  Data  developed  in  this  step  is  summarized  into  a  volume  called  the  MPT 
Resource  Requirements  Document.  The  format  for  the  MPTRRD  is  a 
series  of  summary  worksheets  that  roll  up  the  different  categories  of 
Personnel  resource  requirements  by  fiscal  year,  with  short  narratives  to 
describe  the  various  categories. 

e.  Step  5.  Develop  Program  Documentation  Input 

This  step  is  the  same  as  step  5  in  paragraph  5. 4. 3. 3.1  E/S/S  Application. 

5.4.3. 3. 3  Total  Vessel  Application.  This  MAPTIDES  Methodology  differs  considerably  from 
the  other  applications.  The  Total  Vessel  Application  requires  the  analyst  to  take  into  account 
personnel  cross-utilization,  habitability  constraints,  non-hardware-based  personnel  requirements 
(such  as  watch  stations  and  organizational  support),  and  the  impact  of  multiple  E/S/S 
configurations.  This  application  should  make  maximum  use  of  existing  automated  data  systems 
(i.e.,  models)  to  determine  Personnel  Domain  requirements. 

Despite  these  differences,  the  Total  Vessel  Application  utilizes  the  same  analytical  principles  and 
techniques,  and  it  produces  data  comparable  to  the  other  MAPTIDES  applications.  Because 
Total  Vessel  Acquisition  programs  often  involve  procurement  of  multiple  new  hardware 
components,  this  application  is  designed  to  draw  on  the  Aviation  and  E/S/S  Applications  when 
those  components  are  present  on  new  vessels. 

The  Total  Vessel  Application  is  composed  of  the  following  five  action  steps  that  together  provide 
a  structured  approach  to  Personnel  planning  and  analysis  for  vessels.  See  Exhibit  D-26  for  the 
steps  involved  in  this  application. 

a.  Step  1.  Collect  Preliminary  Total  Vessel  Data 

(1)  This  step  requires  the  analyst  to  collect  and  analyze  preliminary  program 
data  on  the  new  vessel,  including  mission  constraints,  performance  goals, 
and  planned  equipment. 

(2)  Based  on  data  collected,  the  analyst  will  develop  a  description  of  the  total 
vessel  Personnel  requirements  and  initial  vessel  concept  summaries. 

b.  Step  2.  Conduct  Manpower  Engineering  Study 

Step  2  has  three  substeps  to  determine  the  likelihood  of  the  new  vessel  meeting 

its  mission  requirements  and  its  Personnel  supportability. 
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(1)  Using  the  new  vessel’s  equipment  and  mission,  the  analyst  will  describe 
a  notional  vessel  that  will  be  used  to  select  a  Baseline  Comparison  Model. 
The  BCM  will  be  a  complete  vessel  (consisting  of  the  predecessor,  if  there 
is  one,  and  other  systems  similar  to  the  new  vessel),  and  it  will  be  made 
up  of  systems  and  equipment  that  have  established  and  validated  Personnel 
data  approximating  the  requirements  and  constraints  of  the  new  vessel. 

(2)  The  analyst  will  use  the  BCM  equipment  list  to  formulate  inputs  either  to 
the  Navy  Enhanced  Manpower  Determination  Model  (EMDM)  or  to  a 
contractor.  When  the  Navy  model  is  used,  it  is  a  computerized  personnel 
quality  estimation  system  consisting  of  a  series  of  modules  (i.e.,  work 
centers)  that  describe  the  new  vessel.  The  model  takes  cross-utilization 
of  personnel  into  account  to  fully  utilize  all  available  man-hours. 

(3)  Based  on  iterations  of  runs  from  the  model,  or  inputs  from  a  contractor, 
the  analyst  will  prepare  a  Preliminary  Manpower  Report,  including 
Personnel  quality.  See  paragraph  5. 4.2. 3. 3. b. (4)  for  format. 

c.  Step  3.  Determine  Operational  Manpower  Requirements 

(1)  The  Preliminary  Vessel  Manpower  Document  will  be  developed  by  the 
Manpower  analyst,  including  Personnel  quality,  for  a  single  new  vessel. 
This  information  is  then  multiplied  by  the  new  vessel  delivery  schedule  to 
produce  the  Manpower  and  Personnel  requirements  of  the  entire  new 
vessel  class. 

(2)  Developing  the  PVMD  requires  determination  of  workload  requirements. 
This  may  be  done  through  the  Navy  Manpower  Requirements  System 
Model  or  by  contractor.  If  the  Navy  model  is  used,  the  analyst  develops 
workload-related  input  requirements  and  forwards  them  to  the  Navy  to  run 
the  model.  See  Section  5. 4. 2. 3. 3. c. (2)  for  an  explanation  of  the  five 
workload  categories. 

d.  Step  4.  Develop  New  Ship  Training  Requirements  —  In  this  step,  the  analyst  will 

develop  the  training  requirements  of  the  new  vessel  and  produce  a  draft  CGTP. 

See  paragraph  5.4.4  for  a  discussion  of  the  Training  Domain  requirements. 

e.  Step  5.  Develop  Program  Documentation  Input  —  This  step  is  the  same  as  Step 

5  of  the  E/S/S  Application,  paragraph  5.4. 3. 3.1. 

5.4.4  Training  Domain.  Training  consists  of  the  instruction,  time,  and  other  resources 
necessary  to  impart  the  requisite  knowledge,  skills,  and  abilities  to  qualify  personnel  for 
operation,  maintenance,  and  support  of  Coast  Guard  equipment.  Training  strategy  includes  the 
following: 
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a.  Who  is  to  be  trained  (i.e.,  active  component,  reserve,  civilian)? 

b.  What  is  to  be  taught  (i.e.,  system-specific  tasks  and  operationally  critical  tasks)? 

c.  When  is  the  training  to  take  place  (i.e.,  basic  training,  advanced  individual 
training,  and  rate  training)? 

d.  Where  is  the  training  to  take  place  (i.e. ,  institution  —  Coast  Guard,  other  military 
service,  contractor  school  —  or  at  the  unit  level)? 

Training  concepts  answer  the  question  "how?"  the  training  should  be  conducted  (e.g.,  on  the 
actual  equipment,  embedded  training,  training  devices,  or  simulators).  Sustainment  training  to 
maintain  readiness  levels  must  be  considered,  and  it  requires  data  on  anticipated  skill  decay  rates 
and  resource  constraints  (including  time)  at  the  unit  level.  Training  concepts  include  the 
following  considerations: 

a.  Formulation  and  documentation  of  training  strategies  to  qualify  system  personnel 
in  the  most  cost  effective  manner 

b.  Formulation  and  selection  of  engineering  design  alternatives  that  are  supportable 
from  a  training  perspective 

c.  Timely  determination  of  resource  requirements  to  enable  the  Coast  Guard  training 
system  to  support  system  fielding 

d.  Analyses  that  take  into  account  the  expected  aptitude  levels,  previous  training,  the 
nature  and  complexity  of  knowledge  and  skills  to  be  acquired,  and  the  proficiency 
level  to  be  attained  and  sustained.  Identifying  and,  where  possible,  minimizing 
the  requirements  in  these  areas  should  be  an  important  consideration  in  selecting 
engineering  design  alternatives 

e.  The  training  package  for  a  new  system  should  include: 

(1)  A  documented  training  program  for  individuals  and  units  (including  any 
provision  for  embedded  training,  training  devices,  and  team  training  where 
appropriate) 

(2)  The  process  of  transmitting  the  new  knowledge  to  the  Coast  Guard 
(through  factory  training,  training  of  test  personnel,  and  the  evaluation  of 
the  new  training  itself) 

(3)  The  timely  identification  of  the  resource  requirements  to  enable  the  Coast 
Guard  training  establishment  to  support  system  fielding 
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The  increasing  complexity  of  vessels,  aircraft,  and  equipment,  coupled  with  limited  fiscal 
resources  to  meet  increasing  training  costs,  requires  that  the  Coast  Guard  establish  and  maintain 
an  effective  and  efficient  training  system. 

Training  planning  is  a  continuous  process  that  occurs  throughout  the  development  and 
operational  life  of  the  system.  Training  development  follows  the  same  course  as  the 
development  of  the  system  it  will  support.  The  training  plan  begins  in  the  MAPTIDES  analysis 
as  the  development  of  training  concepts  and  requirements  needed  to  support  the  conceptual 
system;  the  training  plan  evolves  into  a  resource  requirements  statement  and  detailed  plan  of 
courses,  student  load,  training  devices,  and  materials  necessary  to  support  a  now  existing 
materiel  system. 

The  MAPTIDES  Methodology  was  designed  to  initiate  the  MPT  planning  process  at  the 
beginning  of  the  acquisition.  This  allows  for  the  production  of  training  planning  data  starting 
in  the  Project  Initiation  Phase.  By  doing  so,  MAPTIDES  makes  possible  the  comparison  of 
alternative  training  concepts  and  the  early  formulation  of  the  training  plan  and  training  resource 
requirements.  Once  determined,  this  allows  ample  lead  time  to  program  for  and  acquire  training 
resources  to  formulate  and  establish  the  training  program  and  to  train  and  assign  personnel. 
Total  training  resource  requirements  to  establish  initial  and  follow-on  training  capability  must 
be  incorporated  in  the  programming  and  budgeting  process  early  during  hardware  development 
and  made  increasingly  definitive  as  the  system  development  progresses. 

To  ensure  effective  training  support  of  the  new  acquisition,  the  continuous  and  substantive 
involvement  of  the  training  community  is  required.  With  the  assistance  of  the  MAPTIDES 
analysis,  early  conceptualization  has  two  distinct  advantages.  First,  it  provides  a  continuous 
"real-time"  picture  of  system-driven  training  requirements  based  on  the  most  current  system  data 
available,  and  it  provides  this  picture  early  enough  to  be  used  in  trade-off  decisions.  Second, 
it  provides  planners  with  information  to  project  gross  long-range  requirements  and  conduct  long- 
range  training  supportability  assessments. 

The  training  planning  should  incorporate  a  totally  unified  approach.  The  identification  of 
training  equipment  and  training  device  requirements,  as  well  as  initiation  of  a  systematic 
approach  to  training  (to  include  the  Instructional  System  Development  (ISD)  process),  should 
begin  in  the  Project  Initiation  Phase.  Training  requirements  are  developed  in  the  MAPTIDES 
analysis  and  are  identified  and  approved  in  the  Coast  Guard  Training  Plan. 

The  determination  as  whether  to  use  the  actual  equipment,  simulated  equipment,  or  combinations 
of  actual  equipment  and  simulators  and/or  training  devices  is  a  judgmental  process.  Selection 
procedures  should  be  employed  that  require  several  alternatives  to  be  evaluated  for  each  new 
training  requirement.  The  evaluation  of  each  alternative  includes  advantages  and  disadvantages 
with  respect  to  life-cycle  cost,  training  effectiveness,  availability  to  support  the  equipment  fleet 
introduction  schedule,  reliability,  maintainability,  energy  and  environmental  impacts,  and 
flexibility. 
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5.4.4. 1  Training  Analyses  Required.  The  Training  domain  requires  iterative  analyses  as  an 
integral  part  of  the  new  system  design  process,  with  Training  analyses  commencing  in  the 
Program  Initiation  Phase. 

Training  analyses  can  commence  when  the  Baseline  Comparison  System  has  been  selected.  The 
first  step  is  to  identify  current  training  requirements  for  the  BCS.  The  following  definitions 
apply: 

a.  Prerequisite  Training  includes  initial  skill  training  (such  as  Class  "A"  school,  as 
well  as  appropriate  Class  "C"  and  some  Class  "FM  schools)  that  is  required  before 
the  principal  course  is  entered. 

b.  Formal  School  is  an  established  Government-run  school  at  which  formal  training 
is  conducted  on  a  recurring  basis. 

c.  Formal  Training  is  the  training  accomplished  by  means  of  structured  training 
actions. 

d.  Informal  Training  is  training  accomplished  by  actions  for  which  structuring  is  not 
specifically  planned  before  hand.  It  includes  on-the-job  training  (OJT)  and 
onboard  training  (OBT). 

The  manpower  and  personnel  quality  requirements  chosen  for  the  IEM  are  used  to  guide  the 
Training  analyst  to  appropriate  numbers  of  students  to  be  trained,  as  well  as  ratings  and  skill 
levels  required.  The  following  data  is  collected  from  the  BCS: 


a.  Type  of  Training 

(1) 

Prerequisite 

(2) 

Formal  School 

(3) 

Formal  Training 

(4) 

Informal  Training 

b.  Category  of  Training 

(1) 

O-Level  Operator 

(2) 

O-Level  Maintenance 

(3) 

I-Level  Maintenance 
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(4)  D-Level  Maintenance 

(5)  Team 

c.  Type  of  Formal  School 

(1)  Officer 

(2)  "A" 

(3)  "C" 

(4)  Other 

d.  The  following  course  information  is  recorded: 

(1)  Course  Title 

(2)  Qualification  Code 

(3)  Course  Identification  Number 

(4)  Date  of  Latest  Schedule 

(5)  Length 

(6)  Attrition 

(7)  Times  Given  Per  Year 

(8)  Class  Size 

(9)  Location 

e.  Type(s)  of  training  resources  applicable  to  courses  is  also  recorded: 

(1)  Training  Devices  —  Simulators  and  other  devices  especially  designed  or 
modified  for  training 

(2)  Technical  Training  Equipment  —  Actual  equipment  developed  by  the 
acquisition  process  for  fleet/field  use,  but  dedicated  to  training 

(3)  Training  Equipment  —  Equipment  used  by  the  fleet/field,  other  than 
Technical  Training  Equipment,  which  is  dedicated  to  training 


D-90 


(4)  Other  Training  Material  —  Includes  instructional  literature,  instructional 
aids,  and  instructional  aids  equipment 

Note:  If  this  equipment  requires  computer  software  dedicated  for  training  it  should  be  included 
in  these  definitions. 

The  Front-End  Analysis  commences  as  soon  after  start  of  the  Project  Initiation  Phase  as 
practical ,  and  is  based  on  a  series  of  specific  tasks.  See  Exhibit  D-23  for  a  description  of  these 
tasks.  The  Front-End  Analysis  calls  for  a  complete  side-by-side  systems  analysis  of  the  BCS, 
and  the  FEA  will  develop  initial  HSI  requirements,  including  training  limitations,  objectives, 
trade-offs,  risks,  and  cost  drivers.  The  results  of  the  analysis  will  be  used  to  provide  inputs  to 
the  major  program  documentation. 

Analysis  of  each  system  design  alternative  considered  is  required  to  determine  the  Training 
requirements  of  each  alternative  to  be  used  in  the  concept  selection  decision.  From  an  HSI 
perspective  (and  there  may  be  other  considerations  as  well),  the  alternative  should  be  selected 
that  offers  the  best  combination  (i.e.,  best  value  to  die  Coast  Guard)  of  high  system 
performance,  low  human  ability  requirements  (i.e.,  numbers  of  people,  aptitudes,  mental  group, 
paygrade,  and  training  burden),  and  low  life-cycle  costs. 

The  MAPTIDES  Methodology  commences  with  data  collection  at  the  same  time  as  the  Front- 
End  Analysis.  See  Exhibit  D-24  for  a  description  of  the  three  applications.  All  applications 
are  conducted  by  the  office  responsible  for  the  HSI  Program.  MAPTIDES  and  the  FEA 
continue  in  parallel.  While  the  FEA  determines  HSI  constraints,  objectives,  etc.,  that  will 
become  inputs  to  the  major  program  documentation,  MAPTIDES  provides  the  detailed 
procedures  for  conducting  the  BCS  analysis  (thereby  also  contributing  to  the  development  of 
information  provided  as  inputs  to  major  program  documents)  and  the  remaining  processes 
necessary  to  determine  life-cycle  Training  requirements  for  the  new  system. 

5.4.4.2  MAPTIDES  Documentation.  The  MAPTIDES  Methodology  continues  through  the 
five-action-step  process  during  the  Concepts  Exploration  and  Demonstration/ Validation  Phases 
(including  updates  in  the  remaining  phases)  to  produce  the  following  Training  documentation. 

a.  For  Aviation  and  E/S/S  Procurements,  the  following  documentation  is  developed: 

(1)  MPT  Concept  Document  (MPTCD)  —  This  document  contains  the 
training  concepts  derived  from  the  manpower  requirements  and  includes 
the  following: 

(a)  Training  Objectives  are  broad  statements  about  why  the  training  is 
going  to  be  conducted.  The  objectives  are  based  on  the  new  E/S/S 
operator  and  maintainer  tasks  and  will  be  the  basis  for  developing 
the  overall  training  strategy. 
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(b)  Preliminary  Training  Approaches  are  how  the  training  will  be 
conducted  through  the  use  of  the  following  types  of  training: 


1  Interservice  Training  is  training  currently  being  conducted 
by  other  services.  Applicable  interservice  training  is 
identified  through  commonality  of  a  Training  objective. 

2  Team  Training  is  training  for  a  group  within  a  single 
dedicated  center  (intragroup  training)  or  for  two  or  more 
dedicated  centers  working  together  (intergroup  training). 

1  Skill  Progression  Training  provides  the  advanced 

knowledge,  skills,  and  techniques  necessary  for  an 
individual  to  operate  and/or  maintain  the  E/S/S.  This  will 
normally  be  a  Class  "C"  or  "F"  school  and  may  lead  to 
award  of  a  qualification  code. 

4  Factory  Training  is  defined  as  training  or  instruction 
provided  by  a  vendor  or  manufacturer  on  how  to  maintain 
and/or  operate  a  specific  piece  of  equipment.  Training  can 
be  conducted  at  the  factory,  at  a  Coast  Guard  school,  or 
aboard  the  unit.  Factory  Training  is  also  known  as 
Contractor  Plant  Services  (CPS)  and  contract  specialized 
training. 

5  Industrial  Training  is  also  normally  provided  by  a  vendor. 
It  is  the  training  given  to  Coast  Guard  civilians  so  they  may 
install  or  inspect  the  installation  of  the  E/S/S. 

(c)  Training  Data  Development  expands  on  the  preliminary  training 

approaches  to  include  the  following: 

1  Training  Location  is  determined  for  skill  progression 
training  that  currently  does  not  exist,  for  training  that  does 
exist  to  determine  if  an  alternative  site  may  be  more 
appropriate,  and  for  training  that  will  be  a  modification  of 
existing  training  to  determine  if  the  existing  site  or  an 
alternative  site  is  more  appropriate. 

2  Training  Collocation  is  the  use  of  the  same  location  for 
more  than  one  course.  This  can  reduce  requirements  for 
training  facilities  and  training  support  materials. 
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2  Training  Integration  is  the  use  of  one  course  to  train 
students  of  one  rating  in  both  operational  and  maintenance 
functions  of  an  E/S/S. 

4  Training  Support  Materials  include  training  devices, 
technical  training  equipment,  training  equipment,  and  other 
training  material  (training  aids,  training  aid  equipment,  and 
instructional  literature).  The  need  for  E/S/S-related 
training  support  materials  for  all  training  in  the  training 
path  is  identified. 

(d)  MPT  Concept  Training  Path  is  a  graphic  training  path  that  must  be 
developed  to  show  the  sequence  and  course  duration  of  initial  skill 
prerequisite  and  skill  progression  training  courses  required  of  an 
E/S/S  trainee. 

(2)  MPT  Resource  Requirements  Document  (MPTRRD)  —  This  document 
details  the  aggregate  training  costs  that  the  training  concept  drives.  The 
MPTRRD  includes  the  following  Coast  Guard-wide  training  resources  and 
costs: 

(a)  Annual  Training  Input  Requirements 

(b)  Required  Training  Devices,  Technical  Training  Equipment,  and 
Training  Equipment  by  Fiscal  Year 

(c)  Other  Training  Material  by  Fiscal  Year  and  Cost 

Both  the  MPTCD  and  MPTRRD  are  iterative  processes.  In  fact,  they  are 
so  dynamic  that  the  documents  should  indicate  the  point  in  the  acquisition 
process  when  they  were  prepared.  The  MPTCD  and  MPTRRD  together 
are  used  to  determine  if  a  Coast  Guard  Training  Plan  is  required;  if  so, 
these  documents  provide  the  inputs  necessary  to  develop  the  Training 
Plan. 

(3)  Coast  Guard  Training  Plan  (CGTP)  —  Inputs  to  develop  the  CGTP  are 
primarily  found  in  the  following  MAPTIDES  documentation:  MPTCD, 
MPTRRD,  and  PAMD.  The  plan  should  be  prepared  by  OHSIP  and  the 
Program  Sponsor  with  technical  assistance  from  G-PRF;  it  should  be 
reviewed  by  the  PM,  appropriate  offices  in  the  Office  of  P,  and  the 
relevant  Training  Centers.  The  draft  Training  Plan  should  then  be 
distributed  to  all  concerned  offices  for  comment.  All  inputs  are  reviewed 
by  the  OHSIP,  Program  Sponsor,  and  the  Office  of  P  to  determine  if 
sufficient  issues  have  been  raised  to  require  a  Training  Plan  Conference; 
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if  so,  the  conference  should  be  co-chaired  by  OHSIP  and  the  Program 
Sponsor.  When  all  issues  are  resolved,  the  Office  of  P  should  review  and 
approve  the  CGTP  for  the  new  system.  Once  approved,  the  plan  should 
be  reviewed  annually  to  accommodate  any  changes  required  and  to  ensure 
adequate  training  support  for  the  life  of  the  system.  The  content  of  the 
Coast  Guard  Training  Plan  includes  the  following: 

Part  1  Training  Program  Data  —  Includes  operational  use,  equipment 
description,  maintenance  concepts,  manpower  concepts,  and 
training  concepts. 

Part  2  Billet  and  Personnel  Requirements  —  Includes  total  annual  billet 
inputs  to  support  the  installation  and  operation  of  the  equipment. 

Part  3  Training  Requirements  —  Includes  location,  course  length,  types 
of  training,  and  training  concept.  It  also  specifies  start  time  of 
schedule  for  all  training  classes  for  the  next  5  years. 

Part  4  Training  Logistics  Support  Requirements  —  Covers  all  of  the 
material  and  data  required  to  support  the  training  environment  and 
training  equipment. 

Part  5  Major  Milestones  —  Shows  all  major  program  milestones,  such  as 
Key  Decision  Points,  and  all  training  milestones. 

Part  6  Actions  or  Decisions  Required  —  Outstanding  agreements  that 
have  not  been  completed,  further  coordination  required  with  a 
platform  or  system,  etc. 

Part  7  Points  of  Contact 


b.  For  Vessel  Procurements,  the  following  training  documentation  is  developed: 

(1)  Preliminary  Vessel  Manpower  Document  —  Step  4.0  of  the  MAPTIDES 
Methodology  for  vessels  is  devoted  to  development  of  new  vessel  training 
requirements.  Products  of  this  step  include  the  following: 

(a)  List  of  Required  Courses 

(b)  Training  Resource  Requirements 

(c)  Training  Manpower  Requirements 
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(d)  Draft  Coast  Guard  Training  Plan 


(2)  Coast  Guard  Training  Plan  —  Inputs  to  this  plan  are  found  in  data 
developed  for  the  PVMD,  as  well  as  other  sources  the  analyst  must  use 
to  generate  required  information.  Other  aspects  of  developing  a  CGTP  for 
new  vessels  are  the  same  as  described  for  Aviation  and  E/S/S 
procurements.  See  paragraph  5.4.4.2.a.(3)  for  format. 

5.4.4.3  MAPTIDES  Methodology  for  Determining  Training  Domain  Requirements.  Analyses 
of  Training  requirements  are  completed  in  each  of  two  different  applications  of  the  MAPTIDES 
Methodology  (see  Exhibit  D-24). 

a.  Both  Aviation  and  E/S/S  procurements  share  the  same  application  of  the 

methodology. 

b.  Total  Vessel  acquisitions  use  a  distinctly  different  application. 

5.4.4.3.1  E/S/S  Application.  This  application  is  used  for  all  procurements  acquired  through 
the  Coast  Guard  acquisition  process,  except  for  aviation  E/S/S  and  vessel  procurements.  Refer 
to  Exhibit  D-25  for  the  steps  used  in  this  application. 

a.  Step  1.  Collect  Preliminary  Data/Conduct  Systems  Analysis 

(1)  Data  is  collected  and  reviewed  by  the  analyst  on  the  new  E/S/S 
requirements,  concepts,  functions,  performance  goals,  performance 
standards,  and  equipment. 

(2)  A  systems  analysis  is  performed  to  select  the  most  appropriate  BCS.  The 
BCS  will  be  based  either  on  the  predecessor  system  or  a  group  of 
comparable  existing  systems  that  best  match  the  new  system  quality 
requirements,  concepts,  performance  standards,  and  equipment.  Training 
requirements  data  are  collected  on  the  platform/activities  where  the  BCS 
is  installed.  See  paragraph  5.4.4. 1  for  analyses  performed  on  the  BCS 
and  the  data  captured. 

(3)  Step  1  initiates  development  of  the  application’s  data  base  and  audit  trail 
used  to  track  the  design  effort  throughout  the  remainder  of  the  project. 

b.  Step  2.  Conduct  Comparability  Analysis 

(1)  This  step  consists  of  a  series  of  procedures  to  assess  differences  in 
resource  requirements  between  the  BCS  and  the  new  system.  This  is  done 
by  comparing  known  parameters  of  the  BCS  with  characteristics  and 
performance  standards  of  the  new  E/S/S. 
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c. 


(2)  A  comparison  is  done  of  both  operator  and  maintainer  functional  tasks 
between  the  BCS  and  new  E/S/S.  This  comparability  analysis  traces  the 
source  of  resource  changes  to  differences  in  requirements,  concepts, 
performance  standards,  and  equipment. 

(3)  Estimates  of  key  training  data  elements  for  new  systems  are  determined 
from  comparable  BCS  values  through  the  formulation  of  deltas.  A  delta 
is  the  estimated  change  in  BCS  values  dictated  by  design,  operational,  and 
functional  changes  in  the  new  system.  See  Appendix  K  for  a  discussion 
of  how  to  determine  deltas. 

Step  3.  Develop  the  Training  Concept 

This  step  consists  of  three  substeps  and  results  in  providing  the  Training  input  to 
development  of  the  MPT  Concept  Document. 

(1)  The  configuration(s)  and  the  installation  schedule  for  the  new  E/S/S  are 
developed.  This  provides  the  analyst  with  the  number  and  types  of 
platforms/activities  where  the  new  E/S/S  will  be  installed,  as  well  as  the 
number  of  installations  by  fiscal  year.  This  information  is  available  from 
the  Program  Sponsor  and  will  be  included  in  the  MNS  and  AP. 

(2)  The  Personnel  quality  portion  of  the  manpower  concept  is  derived  from 
the  qualitative  resource  requirements  for  each  unique  E/S/S  configuration. 
This  information  becomes  an  input  to  developing  the  Training  Plan. 

(3)  The  Training  concept  is  determined  for  each  unique  E/S/S  configuration. 
Training  concept  elements  include: 

(a)  Team  training 

(b)  Initial  (factory)  training 

(c)  Skills  progression  training 

(d)  Training  paths 

(e)  Training  support  materials  concept 

(4)  An  MPT  Concept  Document  is  prepared  by  the  analyst  using  data  from 
the  previous  three  substeps.  See  Appendix  I  for  MPTCD  format.  This 
concept  document  provides  basic  input  to  the  MPT  Resource  Requirements 
Document. 
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d. 


Step  4.  Develop  Manpower,  Personnel,  and  Training  Resource  Requirements 
Document. 


e. 


(1)  In  Step  3,  the  Training  concept  for  operating,  maintaining,  and  supporting 
a  single  E/S/S  configuration  was  determined.  In  Step  4,  Coast  Guard¬ 
wide  training  resource  requirements  are  determined  and  displayed  by 
location  and  by  fiscal  year. 

(2)  Training-associated  manpower  is  also  determined  in  this  step.  The  format 
for  the  MPTRRD  is  a  series  of  worksheets  that  roll  up  the  different 
categories  of  Training  resource  requirements  by  fiscal  year  with  short 
narratives  to  describe  the  various  categories. 

Step  5.  Develop  Program  Documentation  Input 

(1)  The  MAPTIDES  Methodology  is  a  structured  and  systematic  means  of 
addressing  the  many  Training  domain  issues  in  the  Coast  Guard 
acquisition  process.  One  principal  value  of  this  methodology  is  that  it 
produces  a  single  data  source  to  be  used  by  the  OHSIP  to  meet  all  training 
documentation  requirements,  thus  ensuring  consistency  and  comparability. 

(2)  Training  inputs  are  required  in  all  major  program  documentation  and 
should  be  updated  prior  to  each  Key  Decision  Point. 

(3)  Support  for  Training  planning  —  This  section  utilizes  the  MPTCD  and  the 
MPTRRD  to  conduct  training  planning  for  the  operation  and  support  of 
the  new  E/S/S.  The  new  E/S/S-related  training  must  not  only  impart  the 
necessary  knowledge  and  skill,  it  must  also  be  scheduled  so  that  the 
arrival  of  trained  personnel  coincides  with  equipment  arrival.  Training 
planning  is  conducted  in  four  primary  areas. 

(a)  First,  the  Coast  Guard  Training  Plan  is  the  most  significant 
training  document  for  the  new  E/S/S;  it  identifies  tasks,  skills,  and 
necessary  training  courses. 

(b)  Second,  Instructional  System  Development  should  be  used  to 
develop  the  curriculum  necessary  to  impart  the  knowledge  and 
skills  required  to  meet  the  human  performance  objectives  of  the 
new  E/S/S. 

(c)  Third,  training  device  estimates  should  be  made  to  be  consistent 
between  the  CGTP  and  ISD. 
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(d)  And  fourth,  new  facility  construction  requirements  are  estimated 
to  support  Training  for  the  new  E/S/S. 

5.4.4. 3. 2  Aviation  Application.  This  application  is  similar  to  the  E/S/S  application.  See 
Exhibit  D-25  for  the  basic  steps  in  this  application.  It  describes  the  procedures  for  applying  the 
MAPTIDES  Methodology  to  determine  Training  requirements  for  aircraft  and  aviation  E/S/S 
acquisitions.  The  aviation  application  is  comprised  of  the  following  five  steps  that  together 
provide  a  structure  for  training  planning,  analysis,  and  documentation  during  the  Coast  Guard 
acquisition  process. 

a.  Step  1.  Collect  Preliminary  Data  and  Conduct  Systems  Analysis 

This  step  consists  of  three  substeps.  The  analyst  performs  the  following: 

(1)  Collects  and  reviews  data  on  new  Aviation  E/S/S  requirements,  concepts, 
functions,  performance  goals,  performance  standards,  and  equipment. 

(2)  Conducts  systems  analysis  aimed  at  identifying  a  suitable  BCS. 

(3)  Collects  existing  Training  requirements  associated  with  the  transitioning 
unit(s)  and  BCS  elements.  A  transitioning  unit  is  the  organization  that 
employs  the  predecessor  aircraft  and  will  receive  the  new  aircraft. 

Data  from  this  step  are  used  to  initiate  development  of  the  application’s  data  base 
and  audit  trail.  TTiis  data  is  also  used  in  Step  2. 

b.  Step  2.  Conduct  Comparability  Analysis 

This  step  compares  known  parameters  of  the  BCS  with  those  of  the  new  E/S/S 
collected  in  Step  1.  The  objective  is  to  quantify  resource  differences  between  the 
two  E/S/S.  This  is  accomplished  by  comparing  functional  tasks  (both  operator 
and  maintainer)  of  the  BCS  with  the  new  E/S/S.  This  procedure  will  trace  the 
source  of  resource  changes  to  differences  in  requirements,  concepts,  performance 
standards,  or  equipment.  This  assessment  becomes  part  of  the  data  base,  and  the 
resulting  information  is  used  in  the  next  two  steps. 

c.  Step  3.  Develop  the  Training  Concept 
This  step  consists  of  four  substeps. 

(1)  The  analyst  develops  the  installation  schedule  for  the  new  E/S/S.  This 
schedule  provides  information  on  the  number  and  types  of 
platforms/activities  on  which  the  new  E/S/S  will  be  installed,  and  the 
number  of  units  to  be  installed  each  fiscal  year.  Additionally,  for  new 
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aircraft  and  the  aviation  unit,  schedules  are  developed  for  new  aircraft  unit 
stand-up  and  predecessor  squadron  phase-out. 

(2)  If  Navy  training  facilities  are  to  be  used,  the  analyst  conducts  an  analysis 
of  existing  Fleet  Replacement  Squadron  (FRS)  training  to  coordinate 
changes  required  because  of  the  new  E/S/S.  This  analysis  will  estimate 
changes  in  training  for  FRS  operators  and  maintained  (both  organizational 
and  intermediate  levels).  The  analyst  will  also  assess  skill  progression 
training  needs  and  gather  predecessor  course  information. 

(3)  Training  concepts  for  each  unique  E/S/S  configuration  are  determined  by 
the  analyst,  including  initial  factory  training,  skills  progression  training, 
training  paths,  and  training  support  materials  concepts. 

(4)  The  analyst  prepares  the  Training  Domain  portion  of  the  MPT  Concept 
Document.  See  Appendix  I  for  MPTCD  format. 

d.  Step  4.  Develop  Training  Resource  Requirements 

(1)  In  this  step,  total  Coast  Guard-wide  training  resource  requirements  are 
determined  and  displayed  by  location  (installation,  maintenance,  and 
training)  and  by  fiscal  year. 

(2)  Costs  associated  with  initial  hardware  and  course  development,  and  with 
initial  training  facilities  development,  are  also  determined  by  fiscal  year. 

(3)  For  new  aircraft  acquisitions,  total  Coast  Guard-wide  resource 
requirements  are  developed,  first  on  an  aviation-unit  level  and  displayed 
by  fiscal  year.  Additional  Training  requirements  generated  as  a  result  of 
the  aggregation  of  aircraft  into  aviation  units  are  addressed. 

(4)  Data  developed  in  this  step  are  summarized  into  a  volume  called  the  MPT 
Resource  Requirements  Document.  The  format  for  the  MPTRRD  is  a 
series  of  summary  worksheets  that  roll  up  the  different  categories  of 
Training  resource  requirements  by  fiscal  year,  with  short  narratives  to 
describe  the  various  categories. 

e.  Step  5.  Develop  Program  Documentation  Input 

This  step  is  the  same  as  steps  in  paragraph  5.4. 4. 3.1  E/S/S  Application. 

5.4.4. 3. 3  Total  Vessel  Application.  This  application  of  the  MAPTIDES  Methodology  differs 
considerably  from  the  other  applications.  The  Total  Vessel  Application  requires  the  analyst  to 
take  into  account  cross-utilization,  habitability  constraints,  non-hardware-based  requirements 
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(such  as  watch  stations  and  organizational  support),  and  the  impact  of  multiple  E/S/S 
configurations. 

Despite  these  differences,  the  Total  Vessel  Application  utilizes  the  same  analytical  principles  and 
techniques,  and  it  produces  data  comparable  to  the  other  MAPTIDES  applications.  Because 
Total  Vessel  Acquisition  programs  often  involve  procurement  of  multiple  new  hardware 
components,  this  application  is  designed  to  draw  on  the  Aviation  and  E/S/S  Applications  when 
those  components  are  present  on  new  vessels. 

The  Total  Vessel  Application  is  composed  of  the  following  five  action  steps  that  together  provide 
a  structured  approach  to  training  planning  and  analysis  for  vessels.  See  Exhibit  D-26  for  the 
steps  in  this  application.  Training  is  primarily  involved  with  the  BCS  in  Step  2  and  all  of  Step 


a.  Step  1.  Collect  Preliminary  Total  Vessel  Data 

(1)  This  step  requires  the  analyst  to  collect  and  analyze  preliminary  program 
data  on  the  new  vessel,  including  mission  constraints,  performance  goals, 
and  planned  equipment. 

(2)  Based  on  data  collected,  the  analyst  will  develop  a  description  of  the  total 
vessel  Manpower  and  Personnel  requirements  and  initial  vessel  concept 
summaries. 

b.  Step  2.  Conduct  Manpower  Engineering  Study 

(1)  Step  2  determines  the  likelihood  of  the  new  vessel  meeting  its  mission 
requirements  and  its  training  supportability. 

(2)  Using  the  new  vessel’s  equipment  and  mission,  the  analyst  will  describe 
a  notional  vessel  that  will  be  used  to  select  a  Baseline  Comparison  Model. 
The  BCM  will  be  a  complete  vessel  (consisting  of  the  predecessor,  if  there 
is  one,  and  other  systems  similar  to  the  new  vessel).  The  BCM  will  be 
made  up  of  systems  and  equipment  that  have  established  and  validated 
training  data  approximating  the  requirements  and  constraints  of  the  new 
vessel.  Training  data  and  the  IEM  based  on  the  BCS  will  be  used  as  a 
starting  point  for  training  analysis  on  the  new  vessel. 

c.  Step  3.  Determine  Operational  Manpower  Requirements 

The  Preliminary  Vessel  Manpower  Document  is  developed  during  this  step.  The 

manpower  requirements  are  used  to  start  the  training  analysis  and  CGTP. 

d.  Step  4.  Develop  New  Ship  Training  Requirements 
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(1)  In  this  step,  the  analyst  will  develop  the  Training  requirements  of  the  new 
vessel  and  produce  a  draft  CGTP.  The  analyst  will  start  by  determining 
the  training  necessary,  assessing  the  impact  on  existing  training  courses, 
listing  the  specific  courses  required,  and  determining  the  location.  With 
this  information,  the  Training  support  requirements  can  be  determined. 

(2)  The  last  task  in  this  step  is  to  develop  the  CGTP.  It  will  contain  both  the 
system  manpower  and  die  Training  manpower  requirements,  as  well  as  the 
required  courses  and  the  remaining  Training  resource  requirements.  The 
CGTP  will  also  include  the  costs  of  all  Training  resource  requirements. 
See  paragraph  5.4.4.2.a.(3)  for  the  CGTP  format. 

e.  Step  5.  Develop  Program  Documentation  Input 

This  step  is  the  same  as  Step  5  of  the  E/S/S  Application,  paragraph  5.4.4. 3.1. 

5.4.5  Primary  Analytical  Tools  and  Data  Management  Techniques.  The  three  applications  of 
the  MAPTTDES  Methodology  use  established  analytic  and  management  tools  to  determine  MPT 
requirements.  The  major  tools  and  their  relationship  to  the  MAPTIDES  Methodology  are 
discussed  in  the  following  paragraphs. 

5.4.5. 1  Comparability  Analysis.  The  Military  Standard  on  Logistics  Support  Analysis  (MIL- 
STD-1388-1A)  identifies  comparability  analysis  as  the  preferred  method  for  estimating  key 
system  elements  during  the  early  phases  of  the  acquisition  process.  All  applications  of  the 
MAPTIDES  Methodology  are  designed  to  determine  MPT  resource  requirements  during  the 
early  phases  of  the  acquisition  process  by  using  comparability  analysis.  Detailed  data  on  system 
equipment  and  on  key  MPT  data  (e.g.,  tasks)  are  typically  unavailable  during  the  early  phases 
of  the  acquisition  process;  direct  estimates  of  this  data  are  also  typically  unavailable  during  this 
time.  Estimates  of  MPT  resource  requirements  are  difficult  to  make  without  such  data.  To 
avoid  this  problem,  the  MAPTIDES  Methodology  uses  comparability  analysis  to  estimate  these 
key  data  items. 

In  the  Aviation  and  E/S/S  Applications,  the  MAPTIDES  Methodology  identifies  and  analyzes 
a  predecessor  system(s)  and/or  other  comparable  systems  to  produce  a  Baseline  Comparison 
System  to  compare  with  the  new  E/S/S.  In  the  Total  Vessel  Application,  the  methodology 
identifies  and  analyzes  ship  systems  similar  to  those  of  the  new  vessel  to  produce  a  Baseline 
Comparison  Model  that  serves  as  a  benchmark  in  identifying  MPT  resources  for  the  new  vessel. 
The  analyst  extrapolates  the  known  MPT  data  from  the  BCS  or  BCM  to  produce  an  estimate  of 
the  new  vessel  or  E/S/S  MPT  data. 

A  predecessor  system(s)  is  a  system  that  is  currently  performing  the  mission(s)  that  will 
eventually  be  performed  by  the  new  acquisition;  it  is  the  system  that  will  be  replaced  by  the  new 
procurement.  By  definition,  a  predecessor  system(s)  is  a  system  currently  in  the  Coast  Guard 
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inventory.  In  some  cases,  where  a  new  mission  is  created  or  where  new  technology  is 
introduced,  a  predecessor  system  may  not  exist. 

In  cases  where  a  predecessor  system  does  not  exist,  or  is  not  suitable  for  comparability  analysis, 
a  BCS/BCM  is  still  produced.  In  these  cases,  the  BCS/BCM  is  developed  from  comparable 
existing  systems  using  Coast  Guard/DoD/NATO/Civilian  inventory  that: 

a.  Best  meet  the  mission,  operational,  configuration,  and  performance  requirements 
of  the  new  acquisition. 

b.  Have  mature  reliability/maintainability  data  or  maintenance  workload  data  and 
operator  workload  requirements  base. 

c.  Have  the  organization  and  support  concepts  that  most  closely  match  those  of  the 
new  procurement. 

There  may  be  more  than  one  comparable  system.  In  these  cases,  the  "best"  comparable  existing 
system  is  selected.  In  many  instances,  the  predecessor  system  will  be  the  only  system  that 
comprises  the  BCS/BCM.  In  cases  where  the  new  acquisition  assumes  the  mission  of  the 
predecessor  (e.g.,  a  missile  system  replacing  a  gun  system),  there  may  be  no  relationship 
between  the  BCS/BCM  and  the  predecessor  system. 

Compatibility  analysis  allows  the  analyst  to  use  MPT  data  elements  from  the  BCS/BCM  to 
estimate  comparable  data  for  the  new  procurement.  It  modifies  existing  data  to  reflect 
differences  from  the  BCS/BCM  and  the  new  acquisition  and  incorporates  new  technologies  and 
design  differences  into  MPT  requirements  for  the  new  procurements.  During  the  later  phases 
of  the  acquisition  process,  MPT  data  elements  may  be  supplied  directly  by  the  contractor(s)  or 
by  cognizant  Government  agencies. 

Estimates  of  the  key  MPT  data  element  values  for  the  new  acquisition  are  determined  from 
comparable  BCS/BCM  values  dictated  by  design,  operational,  and  functional  changes 
incorporated  in  the  new  procurement.  Deltas  are  applied  by  the  analyst  to  the  appropriate  data 
element  value  to  produce  corresponding  values  for  the  new  acquisition’s  MPT  data  elements. 
A  comprehensive  discussion  of  methods  for  developing  deltas  is  contained  in  Appendix  K. 

5.4.5. 2  Application  Data  Base.  Each  new  acquisition  program  establishes  its  own  data  base. 
The  data  base  is  designed  to  function  as  the  sole  repository  for  all  manpower,  personnel,  and 
training  information  collected  and  developed  throughout  the  conduct  of  each  MAPTIDES 
application.  This  data  base  should  be  automated.  The  data  base,  which  should  be  located  within 
easy  access  of  its  primary  developers  (the  analysts),  will  consist  of  worksheets,  computer 
printouts,  acquisition  documents,  etc.  The  organization  and  maintenance  of  the  data  base  will 
depend  in  part  on  personal  preferences,  prevailing  office  policies,  and  upon  availability  of 
automated  capabilities. 
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The  various  steps,  substeps,  and  procedures  that  comprise  each  application  of  the  MAPTIDES 
Methodology  are  designed  to  develop  a  complete  and  consolidated  MPT  data  base.  The 
steps/substeps  and  procedural  structure  of  the  MAPTIDES  Methodology  build  the  data  base  in 
a  systematic  and  orderly  fashion  as  information  is  collected.  In  addition,  worksheets,  which 
ultimately  record  data  elements  in  the  data  base,  provide  an  audit  trail  for  tracking  the 
development  of  each  MPT  data  element  of  the  new  acquisition. 

5.4.5.3  Audit  Trail.  The  audit  trail  is  a  key  part  of  the  MAPTIDES  Methodology.  It  provides 
the  analyst  with  a  way  of  checking  and  verifying  the  data.  The  audit  trail  is  developed  in  two 
ways.  The  first  aspect  of  the  audit  trail  provides  for  tracking  design,  mission,  and  scenario 
differences  between  the  BCS/BCM  and  the  new  procurement.  These  differences  are  the  sources 
of  deltas  (changes),  which  are  calculated  during  comparability  analysis. 

The  second  aspect  of  the  audit  trail  is  developed  by  utilization  of  audit  trail  spaces  provided  on 
each  MAPTIDES  worksheet.  These  spaces  indicate  "Data  Transferred  From,  "Transfer  Data 
To,”  "Source  of  Data/Date  Prepared." 

Use  of  these  audit  trail  spaces  will  allow  the  analyst  to  trace  the  source  and  application  of  all 
data  recorded  on  worksheets,  backward  and  forward.  This  will  be  most  helpful  during  review. 
In  addition,  the  audit  trail  facilitates  the  ongoing  application  of  the  MAPTIDES  Methodology 
when  personnel  changes  occur  among  the  staff  performing  the  analysis. 

5.4.6  Applicability.  Exhibits  D-28  through  D-34  describe  the  MPT  objectives,  inputs  used, 
products  developed,  and  major  tasks  performed  in  each  of  the  seven  Coast  Guard  acquisition 
phases.  Coupling  these  more  technical  activities  with  the  HSI  Program  Management  actions, 
discussed  in  paragraph  5.1,  completes  the  MPT  processes  required  to  impact  system  design  and 
determine  life-cycle  MPT  requirements  for  the  new  acquisition. 
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Exhibit  D-33.  MPT  Domains  in  the  Production  Phase 


i n 
3 

cr 

o 

co 

£ 

c  3 

O  3 

•  ®  s 

2  E  3 

aSs 

a  o 

h-  ^  iS 
Q.  co  co 

2  =  -o 

eth 

5  S  S 

®  3  & 

£9-3 

3  -E  CT 
—  .  Q) 

1  a  = 
«  5  n 
©  ©  ® 
^  S  3 
ro  >  q. 
C  o  (D 
L  CL  O 

t-’  rg  cr> 


©  « 

O  3 
i-  "D 

n 

3  a) 

T5  C/5 
C  C/5 
53  05 


CL  CL 


C  0. 
O  O 
Q5 

tl 

8  h- 

05  CL 

I  2 

3  a) 

8  s 

O  CL 


"O  05 

£  » 

CO  3 

*8  £ 

E  » 

CO  05 
CD  C/5 
"•  CO 

g  ■? 

o  co 
52  co 

C/5  -T5 
05  ^ 


>  S 

0  05 

Q  CC 


CM  CO  ^ 

I  A  A  4 


D-110 


Exhibit  D-34  .  MPT  Domains  in  the  Deployment  Phase 
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SECTION  E 

HSI  IN  ALTERNATE  ACQUISITION  STRATEGIES 


The  Coast  Guard  has  traditionally  used  the  full  development  Life-Cycle  Model  to  develop  and 
acquire  new  equipment.  Declining  resources  and  the  associated  need  to  field  systems  in  the  least 
possible  time,  however,  make  alternatives  to  full  developmental  programs  increasingly  attractive. 
Similarly,  the  streamlining  and  tailoring  of  the  acquisition  process,  both  for  full  development 
programs  and  alternative  strategies,  is  a  necessary  part  of  efficient  planning. 

1.  SPECTRUM  OF  ACQUISITION  STRATEGY.  Refer  to  Exhibit  E-l  below.  In  developing 
acquisition  strategy,  planners  should  first  consider  improving  or  reconfiguring  the  existing 
materiel  system  (i.e.,  a  materiel  change),  followed  by  use  of  the  most  appropriate  form  of  Non- 
Developmental  Item  (NDI),  and  finally,  development  of  a  new  system.  All  acquisition  strategies 
should  use  appropriate  tailoring  to  hold  down  costs  while  requiring  enough  analyses  and  data  to 
make  appropriate  decisions.  Acquisition  alternatives  can  also  include  the  use  of  commercial 
components  and  subsystems  for  integration  into  a  new  development  system. 


TRADITIONAL  OR  TAILORED  m 

NON  DEVELOPMENTAL  ITEM 

Materiel  Change  or  New  System 

NDI 

Integration 

NDI  Adaptation 

Basic 

NDI 

Full 
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Program 

Development 
with  Standard 
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Development 

with 

Standard 

Subsvstems 

Assemblage 
of  Standard 
Subsystems 

Militarize 

Ruggedize 

Classic  NDI 

Off-the-Shelf 

Out-of-Catalog 

Exhibit  E-l.  Available  Acquisition  Alternatives 


From  a  Human  System  Integration  (HSI)  perspective,  the  challenge  in  any  acquisition  alternative 
is  the  ability  to  influence  system  design.  This  ability  requires  early  involvement  in  the 
procurement  by  the  OHSIP  regardless  of  the  acquisition  strategy  (i.e.,  whether  traditional, 
tailored,  or  NDI).  For  most  of  these  alternative  strategies,  the  time  available  to  perform  HSI 
analyses  is  significantly  reduced  compared  to  the  traditional  full  development  program.  For  NDI 
programs,  system  design  may  already  be  complete,  and  HSI  may  only  serve  as  a  means  to 
discriminate  between  candidate  systems  (this  is,  however,  an  important  role  to  ensure  the  new 
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NDI  is  compatible  with  the  capabilities  and  limitations  of  the  Coast  Guardsmen  that  must 
operate,  maintain,  and  support  the  equipment). 

2.  ADVANTAGES  AND  DISADVANTAGES  OF  ALTERNATIVE  ACQUISITION 
STRATEGIES.  Despite  the  reduced  time  expected  for  HSI  analyses,  alternative  acquisition 
strategies  offer  significant  advantages: 

a.  The  time  to  field  equipment  is  reduced,  providing  increased  responsiveness  to  the 
field. 

b.  Research  and  development  costs  are  reduced,  thereby  lowering  overall  acquisition 
costs. 

c.  State-of-the-art  technology  is  utilized  to  satisfy  user  needs. 

d.  The  mobilization  base  is  expanded  to  include  available  commercial  production 
facilities. 

e.  Available  provisioning  manuals  and  special  tools  can  be  used  to  reduce  logistic 
support  costs. 

Along  with  these  advantages,  there  are  also  areas  of  concern  that  must  be  considered: 

a.  The  new  system  may  not  meet  all  user  requirements. 

b.  Integrated  Logistic  Support  (ILS)  activities,  normally  accomplished  in  pre- 
production  phases,  must  be  accelerated  increasing  up-front  costs. 

c.  Proliferation  of  hardware  and  software  systems  may  result,  causing  logistics 
support,  training,  and  configuration  management  problems. 

d.  Inherent  safety  deficiencies  may  pose  unacceptable  risks. 

e.  Program  management  documents,  such  as  the  Operational  Requirements 
Document  (ORD)  and  HSI  System  Management  Plan  (HSISMP),  must  be 
expedited  for  the  shorter  acquisition  cycle. 

f.  Human  Factors  Engineering  (HFE)  issues  may  not  be  adequately  addressed. 

3.  ACQUISITION  ALTERNATIVES.  Once  the  need  for  a  materiel  solution  has  been 
determined,  the  acquisition  strategy  selection  starts  with  improvement  or  reconfiguration  of  the 
existing  materiel  system,  followed  by  the  use  of  NDI,  and  finally,  the  development  of  a  new 
system.  The  HSI  procedures  used  to  support  the  traditional  full  development  program  are 
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applicable  to  all  acquisition  strategy  alternatives.  However,  each  strategy  requires  a  tailored  HSI 
approach,  based  on  the  complexity,  cost,  and  schedule  constraints  of  the  program. 

3.1  HSI  in  Materiel  Change.  Materiel  change  involves  the  modification  or  reconfiguration  of 
a  fielded  system  to  provide  new  or  improved  capabilities,  extend  the  system’s  useful  life, 
improve  safety  or  readiness,  or  reduce  operation  or  support  costs.  In  some  cases,  a  materiel 
change  may  be  required  to  correct  a  system’s  HSI  deficiencies  that  have  been  documented  in  the 
HSISMP. 

The  materiel  change  program  can  range  in  complexity  from  the  modification  of  a  subsystem  for 
safety  or  health  reasons  to  major  modifications  which  will  expand  the  operational  performance 
envelope  and  result  in  an  essentially  new  system. 

When  evaluating  the  impact  of  a  proposed  materiel  change,  a  total  system  perspective  must  be 
used  so  that  implications  from  all  five  HSI  domains  can  be  adequately  appraised.  If  an  HSISMP 
for  the  system  already  exists,  the  HSI  Joint  Working  Group’s  (HSDWG’s)  materiel  change 
assessment  should  be  noted  and  appended  to  Tab  G  -  Audit  Trail  (see  Appendix  E  for  HSISMP 
format). 

When  a  proposed  materiel  change  has  HSI  implications,  a  crosswalk  of  system  performance 
information  contained  in  key  program  documents  is  required.  Supporting  program  documents 
should  be  modified  to  reflect  HSI  considerations.  Once  the  materiel  change  proposal  and 
support  documentation  have  been  staffed,  the  Configuration  Control  Board  (CCB)  will  meet  to 
consider  the  proposed  change.  Based  on  the  information  presented,  the  CCB  should  develop  the 
technical  recommendation  and  validate  the  decision  level  for  the  materiel  change. 

In-house  or  contractor  requirements  for  modifications  should  include  HSI  constraints. 
Engineering  Change  Proposals  (ECP)  and  Materiel  Change  Packages  (MCP)  should  be  reviewed 
to  ensure  that  human  performance  problems,  such  as  increased  manpower  requirements, 
additional  skill  requirements,  or  increased  training  times,  are  not  unintentionally  designed  into 
the  modified  system. 

Depending  on  the  degree  of  the  materiel  change,  testing  will  be  required  to  ensure  that  the 
change  is  technically  adequate  and  that  it  achieves  the  user’s  desired  operational  requirements. 
The  need  to  assess  a  materiel  change  from  an  HSI  perspective  should  be  included  in  the  system’s 
Test  and  Evaluation  Master  Plan.  The  decision  authority  at  Key  Decision  Points  will  review  all 
data  and  either  approve  or  disapprove  the  materiel  change. 

3.2  HSI  in  Evolutionary  Acquisition  (EAl.  EA  provides  the  deferred  insertion  of  emerging 
technologies  in  a  new  materiel  system.  EA  programs  complement  near-term  acquisitions  by 
providing  for  parallel  or  phased  development  and  future  incorporation  of  added  capabilities 
without  increasing  the  near-term  risk.  These  planned  improvements,  or  "block  mods,"  are 
programmed  during  basic  system  development. 
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EA  requires  pre-planning  and  up-front  equipment  design  to  allow  for  specific  future  upgrades. 
HSI  implications  should  be  addressed  during  the  development  of  the  primary  system  using  the 
procedures  described  for  the  traditional  acquisition  strategy.  However,  since  the  definition  of 
the  final  system  is  often  not  completed  until  late  in  the  basic  system  development  cycle,  the 
HSUWG  must  remain  involved  in  the  development  throughout  the  acquisition  and  deployment 
process. 

3.3  Non-Developmental  Item  Acquisitions.  NDI  procurements  require  little  or  no  development 
effort  by  the  Coast  Guard.  Normal  sources  of  NDI  materiel  include  commercial  products  (which 
may  or  may  not  require  modification),  materiel  used  by  other  U.S.  military  services  or 
Government  agencies,  and  materiel  used  by  other  countries.  NDI  acquisitions  are  preferred 
when  a  materiel  change  is  not  feasible  and  when  the  market  analysis  process  demonstrates  that 
commercial-off-the-shelf  items  are  currently  available  that  meet  user  needs. 

Significant  examples  of  NDI  programs  include  the  Army’s  modification  of  a  Chevrolet  Blazer 
to  perform  as  its  Commercial  Utility  Cargo  Vehicle,  Navy  selection  of  an  Israeli-  developed 
short-range  remotely  piloted  vehicle,  and  the  Air  Force  adoption  of  a  McDonnell  Douglas 
passenger/freight  aircraft  to  become  the  KC-10  tanker. 

3.3.1  Types  of  NDI.  A  common  misconception  is  that  NDI  and  commercial-off-the-shelf 
equipment  are  synonymous.  As  shown  in  the  Available  Acquisition  Alternatives  (Exhibit  E-l), 
there  are  three  categories  of  NDI  procurements,  and  the  HSI  applications  will  vary  accordingly. 

a.  Basic  NDI.  Basic  NDI  procurement  involves  an  off-the-shelf  item  (commercial, 
foreign,  other  service)  that  will  be  used  in  essentially  the  same  application  and 
environment  for  which  it  has  been  designed.  For  this  category,  since  the  design 
is  not  changed,  HSI  can  serve  as  a  means  to  discriminate  between  existing 
candidate  systems. 

b.  NDI  Adaption.  An  NDI  Adaption  procurement  involves  an  off-the-shelf  item 
(commercial,  foreign,  other  service)  that  will  be  used  in  an  application  or 
environment  other  than  that  for  which  it  has  been  designed.  In  this  case,  the  item 
often  requires  ruggedization  or  militarization.  Although  these  modifications 
constitute  "design  changes,"  the  opportunity  for  hardware  redesign  as  a  result  of 
HSI  is  usually  minimal. 

c.  NDI  Integration.  This  category  of  NDI  refers  to  a  procurement  that  makes 
maximum  use  of  NDI  items  as  subsystems,  modules,  or  components  in  a  low- 
risk  system  integration.  This  category  requires  a  dedicated  Research  and 
Development  (R&D)  effort  for  systems  engineering,  modification,  and  testing  to 
ensure  that  selected  NDIs  work  together  as  an  integrated  system  that  meets  the 
user  requirements.  In  this  category,  there  may  be  opportunities  for  HSI  to  make 
inputs  to  the  system  integration  and  design. 
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3.3.2  HSI  in  NDI  Acquisitions.  For  NDI  acquisitions,  HSI  must  focus  on  the  acceptability  of 
using  an  existing  or  a  slightly  modified  system.  While  NDI  acquisitions  are  promising  from  a 
time,  cost,  and  technology  standpoint,  they  require  flexibility  by  the  user  of  the  system  and  an 
early  awareness  of  possible  requirement  trade-offs. 

One  of  the  major  differences  between  NDI  and  the  traditional  full  development  program  is 
emphasis  on  the  market  analysis  process.  Market  analysis  activities  provide  the  information 
necessary  to  determine  whether  to  pursue  an  NDI  solution,  and  to  evaluate  the  HSI  implications 
of  the  candidate  systems.  Market  analysis  is  conducted  in  two  phases:  market  surveillance  and 
market  investigation. 

Market  surveillance  establishes  the  feasibility  of  NDI  as  an  acquisition  strategy.  Feasibility 
refers  to  the  availability  of  commercial  products  with  the  potential  to  satisfy  the  materiel  need. 
Market  surveillance  should  be  a  continuous  activity  of  the  Coast  Guard  Research  and 
Development  Center.  It  is  the  activity  by  which  the  Coast  Guard  can  maintain  an  awareness  of 
the  technologies  and  products  being  developed  in  the  private  sector  (including  foreign  products) 
that  may  be  adaptable  for  Coast  Guard  use. 

NDI  feasibility  is  assessed  based  on  the  initial  operational  requirements  developed  by  the 
Program  Sponsor  and  the  available  market  surveillance  information.  Since  no  formal  method 
exists  to  ensure  that  human  performance  issues  are  identified  during  the  NDI  feasibility 
determination,  the  HSI  constraints  and  goals  included  in  the  HSISMP  and  early  requirements 
documents  must  be  communicated  to  those  responsible  for  conducting  the  market  surveillance. 

If  an  NDI  acquisition  strategy  is  determined  feasible,  a  market  investigation  is  conducted.  The 
market  investigation  involves  a  detailed  search  for  information  tailored  to  the  specific  materiel 
need.  The  HSISMP  serves  as  the  basis  for  developing  the  operational  issues  and  evaluation 
criteria  to  be  addressed. 

As  a  result  of  the  market  investigation,  an  assessment  is  made  of  the  availability  of  hardware 
and  software  that  meets  the  operational  and  performance  requirements.  Additionally, 
performance  limitations  and  possible  requirements  trade-offs  are  identified.  As  the  user 
requirements  become  more  defined,  the  ORD  is  developed,  which  serves  as  the  basis  for  the 
solicitation. 

3.4  Tailoring  and  Streamlining  the  Acquisition  Process.  While  the  traditional  full  development 
program  considers  the  full  range  of  complexity  and  risk  factors  for  a  wide  spectrum  of 
programs,  the  need  to  reduce  costs  and  effect  early  fielding  encourages  tailoring  and  streamlining 
of  all  acquisition  alternatives.  The  ultimate  goal  of  acquisition  streamlining  is  to  reduce  the  cost 
and  time  it  takes  to  field  operationally  suitable  materiel  systems  and  their  supporting  services. 

Streamlining  is  a  combination  of  common  sense  measures  to  achieve  the  "surest  and  shortest" 
path  of  low-risk  development  programs.  It  is  a  tailored  development  approach  that  emphasizes 
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performance-oriented  requirements  and  the  pursuit  of  materiel  solutions  using  mature 
components  or  subsystems. 


3*4.1  HSI  in  Acquisition  Streamlining.  The  application  of  HSI  in  streamlining  an  acquisition 
is  essentially  the  same  as  for  a  traditional  development  program.  Streamlining  can  reduce  the 
full  development  time  from  2  to  8  years.  The  decision  matrix/criteria  shown  in  Exhibit  E-2 
should  be  followed  in  making  the  initial  assessment  as  to  the  level  of  HSI  effort  required  for  the 
system  under  consideration  and  to  determine  whether  or  not  an  abbreviated  HSI  System 
Management  Plan  or  a  full  management  plan  is  appropriate. 

The  following  paragraphs  describe  streamlining  and  tailoring  considerations  throughout  the 
acquisition  process. 

a-  Requirements  Determination.  The  HSISMP  is  the  key  human  performance 
document  for  the  streamlined  approach.  An  early  understanding  of  the  HSI  issues 
associated  with  the  application  of  new  technology  is  necessary  so  that  an 
acquisition  strategy  that  addresses  the  full  range  of  NDI,  materiel  change,  and  full 
development  solutions  can  be  developed.  Front-End  Analyses  specified  in  the 
HSISMP  will  assist  in  defining  the  extent  of  HSI  issues  and  their  impact  on 
expected  system  performance.  HSI  analyses  and  technical  base  activities  will 
assist  in  the  development  of  system  requirements  that  are  stated  in  operational 
terms  with  allowable  bands  of  performance. 

h.  Proof-of-Principle  Activities.  The  proof-of-principle  phase  provides  about  a  2- 
year  period  to  prove  out  the  technologies  selected  for  inclusion  in  the  new  system 
and  to  formalize  the  concept  formulation  process.  It  allows  for  an  early  "pulse 
check"  with  senior  leadership  on  the  system  requirements  and  basic  program 
acquisition  strategy  approach.  The  phase  is  concluded  with  a  combined  KDP-2 
and-3  "go/no  go"  decision  that  can  permit  a  program  to  proceed  directly  to  Full 
Scale  Development  and  then  to  Production. 

Since  much  of  the  information  available  early  in  the  acquisition  process  will  come 
from  the  market  investigation,  HSI  issues  identified  in  the  HSISMP  must  be 
addressed.  The  results  of  the  market  investigation  will  form  the  basis  for  an 
acquisition  strategy  decision  and  will  finalize  the  ORD.  Marketplace  features 
(equipment  characteristics)  that  enhance  human  performance  must  be  identified 
and  included  as  system  requirements  in  the  ORD.  Unrealistic  requirements,  those 
which  add  little  value,  and  those  that  detract  from  human  performance,  must  be 
eliminated. 

The  selection  of  the  acquisition  strategy  (incorporation  of  NDI,  materiel  change, 
or  full  development)  is  closely  linked  with  the  requirements  process.  It  is  often 
necessary  for  the  user  to  identify  performance  requirements  that  can  be  traded  off 
to  make  an  acquisition  alternative  viable.  The  results  of  HSI  analyses  will 
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Exhibit  E-2.  HSISMP  Decision  Graphic 


provide  the  decision  makers  with  information  that  will  make  this  process  easier. 
Care  must  be  taken  to  ensure  that  undesirable  features  are  not  added  for  the  sake 
of  "making  the  system  work." 

Proof-of-principle  activities  stress  user  experimentation  and  personnel 
demonstrations  with  "brassboard"  systems,  components,  and  surrogates  or  models 
to  prove  out  the  operational  concept  before  proceeding  to  Full  Scale 
Development.  Inclusion  of  HSI  issues  and  criteria  in  the  Test  and  Evaluation 
Master  Plan  ensures  that  human  performance  information  will  be  collected  and 
addressed  during  the  test  program. 

c.  Development  Proveout  Activities.  Development  proveout  activities  focus  on  the 
integration  of  the  mature  technologies  and  systems  demonstrated  during  proof-of- 
principle.  This  phase  includes  the  Full  Scale  Development  of  hard-tooled 
prototypes  and  low  rate  production  items  prior  to  actual  entry  into  full  rate 
production. 

Residual  HSI  issues  documented  in  the  HSISMP  are  addressed  through 
operational/pre-production  testing  prior  to  a  KDP-4  decision.  Integrated 
technical/user  testing  is  used  to  the  maximum  extent  possible  to  reduce  test  costs 
and  time  requirements.  Early  testing  and  continuous  evaluation  reduce  the  risk 
that  the  hard-tooled  prototypes  will  have  human  performance  problems  that  may 
require  significant  engineering  changes.  The  results  of  testing  should  allow  type 
classification,  thereby  permitting  a  production  decision. 

Solicitation  and  contractual  documents  are  streamlined  by  including  a  minimum 
of  "how  to"  guidance  and  eliminating  non-productive  or  non-cost  effective  data 
requirements.  Tailoring  of  data  items  to  the  information  absolutely  necessary  to 
satisfy  specific  HSI  and  other  requirements  can  result  in  substantial  savings. 
Human  performance  information  can  be  obtained  by  using  safety,  health  hazards, 
ILS,  and  HFE  Data  Item  Descriptions  (DIDs)  and  data  requests. 

d.  Full  Rate  Production  and  Initial  Deployment.  The  transition  from  hard-tooled 
prototypes  to  production  items  provides  minimal  opportunity  for  major  design 
changes.  Therefore,  the  HSI  efforts  during  this  phase  center  on  source  selection 
and  supportability.  HSI  should  be  accorded  equal  priority  with  other  system 
characteristics  to  ensure  effective  human-equipment  interface.  HSI  criteria  must 
be  an  integral  part  of  all  selection  criteria  in  each  area  of  proposal  evaluation. 

During  initial  deployment,  the  system’s  supportability  must  be  thoroughly 
reviewed  to  assess  its  HSI  impact  and  provide  a  baseline  for  evaluating  proposed 
engineering  change  proposals.  HSI  data  collected  will  provide  the  foundation  for 
the  development  of  next  generation  and  notional  systems. 
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Other  Streamlining  Considerations.  The  following  are  four  practical 
considerations  in  streamlining  acquisitions. 

(1)  Don’t  let  "better"  be  the  enemy  of  "good  enough."  Success  in 
streamlining  rests  in  large  part  on  willingness  to  limit  objectives  -  to  stick 
to  mature  technology  when  the  temptation  is  to  go  for  a  high  technology 
breakthrough. 

(2)  Maximize  coordination  and  cooperation.  Streamlining  will  not  make  the 
job  easier;  rather,  it  requires  additional  effort  to  ensure  that  all  bases  are 
covered  and  everyone  is  in  agreement  with  the  program. 

(3)  Minimize  verbiage.  Rigorous  writing  is  concise.  Don’t  waste  words. 

(4)  If  it  doesn’t  make  sense,  don’t  do  it.  In  streamlining,  nothing  is  sacred. 
Too  many  requirements  exist  only  because  they  were  in  a  previous 
solicitation  or  program.  Challenge  them.  If  they  provide  little  or  no 
benefit  to  a  program,  they  should  be  eliminated. 

These  rules,  coupled  with  common  sense  and  trust,  form  the  basis  of  effective 
streamlining.  They  apply  equally  to  government  and  industry  because  both  have 
the  same  fundamental  goal  --  to  get  quality  equipment  into  the  hands  of  the  Coast 
Guardsman  more  quickly  and  at  a  reduced  cost.  Streamlining  can  make  it 
happen. 
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SECTION  F 

IMPLEMENTING  HSI  IN  COAST  GUARD  ACQUISITION  PROCESS 


In  Section  A,  paragraph  5  of  the  Coast  Guard  HSI  Program  Requirements  Document  (the  first 
deliverable  in  this  Project),  we  described  several  potential  staff  organization  options  in  assigning 
management  responsibility  for  implementing  the  HSI  Program  in  Coast  Guard  acquisitions.  No 
final  organizational  recommendation  was  made  at  that  time,  pending  completion  of  the  Coast 
Guard  HSI  Process  Model.  The  HSI  Process  Model,  as  described  in  this  document,  has  further 
defined  the  various  activities  that  must  be  completed,  the  coordination  required,  and  the 
recommended  management  structure  necessary  to  properly  manage  HSI  through  the  Coast  Guard 
procurement  process.  Accordingly,  based  on  our  understanding  of  the  Coast  Guard  acquisition 
system  and  the  HSI  Process  Model  as  described  herein,  we  now  have  enough  information  to 
recommend  staff  organizational  assignments  to  efficiently  integrate  HSI  into  the  process.  The 
following  paragraphs  describe  the  recommended  staff  organizational  responsibility  for  managing 
the  HSI  Program. 

1.  OFFICE  RESPONSIBLE  FOR  THE  HSI  PROGRAM.  The  early  involvement  of  OHSIP 
in  each  acquisition  well  in  advance  of  the  PMs  assignment;  the  coordination  required  between 
the  HFE  and  the  Design  Engineers  to  work  design  changes  from  all  five  domains  and  the  wide 
array  of  organizations  the  OHSIP  must  successfully  interface  with  in  performing  their  HSI  duties 
—  all  three  factors  support  and  reenforce  our  earlier  findings  that  the  strongest,  most  workable 
organizational  option  for  managing  HSI  is  a  separate  HSI  Program  Office  established  in  the 
Office  of  Acquisition. 

If  the  HSI  Program  is  to  succeed,  it  must  impact  system  design.  To  influence  system  design, 
the  OHSIP  must  start  the  Front-End  Analysis  and  MAPTIDES  Methodology  early  in  the  Project 
Initiation  Phase.  OHSIP  must  also  establish  effective  interface  relationships  with  other  staff 
organizations  as  described  in  Section  C.  To  accomplish  these  critical  tasks,  OHSIP  needs  the 
strategic  positioning  offered  by  assignment  to  the  Office  of  Acquisition.  Assignment  to  the 
organization  responsible  for  the  proper  functioning  of  the  Coast  Guard  acquisition  process  will 
provide  OHSIP  the  most  effective  positioning  to  mold  and  fit  the  HSI  Program  into  the  existing 
acquisition  process.  This  organizational  positioning  will  also  allow  OHSIP  to  smoothly  and 
successfully  establish  the  various  working  relationships  required  and  to  be  involved  with  the 
Program  Sponsor  in  the  early  stages  of  each  new  acquisition. 

For  HSI  to  successfully  impact  system  design,  the  Human  Factors  Engineer  (HFE)  must 
coordinate  domain  problems  impacting  design  with  the  domain  expert  to  find  an  acceptable 
solution.  The  HFE  must  then  coordinate  the  solution  with  Design  Engineers  to  alter  the  design 
and  resolve  the  domain  issue.  To  effect  this  coordination,  the  HFE  must  be  involved  on  a 
regular  basis  with  both  systems  and  design  engineering  (including  hardware/software  contractors) 
to  understand  enough  about  the  current  design  to  develop  credible  alternatives  in  solving  domain 
issues.  This  process  will  work  better  and  the  HFE  will  be  more  credible  with  the  engineering 
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organizations  if  the  OHSIP  is  assigned  to  the  Office  of  Acquistion,  which  is  dedicated  to  making 
the  whole  acquisition  process  work. 

To  properly  implement  HSI,  the  OHSIP  must  interface  at  some  time  with  almost  every 
organization  in  the  Coast  Guard  (although  perhaps  not  on  every  acquisition).  These  interfaces 
and  the  relationships  established  will  be  more  credible  and  more  amicable  if  OHSIP  is  from  an 
organization  that  does  not  represent  a  particular  interest  or  function.  Here  again,  the  Office  of 
Acquisition  is  the  best  choice. 

In  addition,  solely  dedicating  the  HSI  Team  to  managing  HSI  in  all  system  acquisitions  builds 
expertise  and  promotes  continuity  in  HSI  requirements  development,  domain  procedures,  and 
documentation  from  one  acquisition  to  the  next.  This  arrangement  also  promotes  building 
extensive  lessons-leamed  data  bases  in  each  domain  over  time. 

For  all  of  these  reasons,  we  recommend  the  HSI  Program  Office  be  established  as  a  separate 
Branch  and  be  located  in  the  Office  of  Acquisition. 


2.1  HSI  PROGRAM  OFFICE  STAFFING.  All  HSI  domains  can  be  covered  by  specialists 
assigned  to  the  following  five  positions.  Specialists  in  these  positions  will  coordinate  their 
domain  requirements  and  products  with  the  office  indicated.  This  coordination  is  a  way  of 
focusing  and  utilizing  Coast  Guard  institutional  HSI  domain  expertise  to  ensure  the  best  possible 
inputs  for  each  system  acquisition;  additionally,  this  is  a  way  to  keep  the  coordinating  offices 
advised  of  new  HSI  requirements  in  their  areas  of  responsibility. 


Position 


Coordinating  Office 


Human  Factors  Engineer 
Safety  Engineer 
Manpower  Specialist 
Personnel  Specialist 
Training  Specialist 


Coast  Guard  R&D  Center 
G-K 
G-CPA 
G-PWP 
G-PRF 


The  HSI  Program  Office  should  be  headed  by  a  Human  Factors  Engineer  because  the  HFE  is 
specifically  trained  in  all  HSI  domains.  In  addition,  the  HFE  brings  to  the  HSI  team  an 
engineering  perspective  to  resolve  design  issues  in  all  domains  and  to  coordinate  those 
resolutions  with  Design  Engineers.  The  HFE  understands  systems  engineering  and  design  and 
will  be  a  credible  member  of  the  acquisition  team  in  resolving  HSI  domain  problems  and 
reflecting  those  corrections  in  the  system  design. 

Since  there  are  no  Human  Factors  Engineers  or  Safety  Engineers  on  the  staff,  this  option  will 
require  the  Coast  Guard  to  invest  in  the  HSI  Program  by  creating  two  positions  and  hiring  a 
Human  Factors  Engineer  and  Safety  Engineer.  This  organization  option  ensures  by  far  the  most 


F-2 


effective  HSI  Program  over  the  other  options.  For  a  relatively  small  investment  in  manpower, 
the  Coast  Guard  will  gain  an  HSI  capability  that  is  not  present  today.  In  addition  to  greatly 
improved  system  performance,  this  program  will  result  in  cost  avoidance  that  is  much  greater 
than  the  manpower  costs  required  to  implement  HSI. 
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APPENDIX  A 


REFERENCES 


Department  of  Transportation  Orders 
4200. 14C  Major  Acquisition 

U.S.  Coast  Guard  Instructions 


Commandant.  Instructions 


1550.9 

4000.5 

4105.2 


M4105.2 

M4150.2C 

M5400.7C 

M55312.11A 


Management  of  the  Coast  Guard’s  Training  System 
Coast  Guard  Logistics  Doctrine 

(Draft)  Acquisition  and  management  of  Integrated  Logistics 
Support  (ILS)  for  Coast  Guard  Systems  and  Equipment 
Acquisition  Review  council,  Coast  Guard  (CGARC) 

Systems  Acquisition  Manual 
Organization  Manual 
Staffing  and  Standards  Manual 


Headauartes  Instructions 

4081.2  Operational  Logistics  Support  Plan  (OLSP)  Development  and 

Management  Responsibility 

4200. 10  Acquisition  Review  Council,  Coast  Guard  (CGARC) 


Military  Standards/Specifications/Handbooks 


MEL-STD-245 

MIL-STD-280 

DoD-HDBK-292  (Navy) 
MIL-STD-480B 

MIL-STD-483A  (USAF) 

MIL-STD-490 
MIL-STD-499A 
DoD  -HDBK-743 
DoD-HDBK-759 
DoD-HDBK-761 

DoD-HDBK-763 

MIL-STD-881A 

MIL-STD-882B 


Preparation  of  Statement  of  Work  (SOW) 

Definition  of  Item  Levels,  Item  Interchangeability,  Models  and 
Related  Terms 

Training  Materials  Development 

Configuration  Control— Engineering  Changes,  Deviations,  and 
Waivers 

Configuration  Management  Practices  for  Systems,  Equipment, 
Munitions,  and  Computer  Programs 
Specification  Practices 
Engineering  Management 

Anthropometry  of  U.S.  Military  Personnel  (Metric) 

Human  Factors  Engineering  Design  for  Army  Materiel 

Human  Engineering  Guidelines  for  Management  Information 

Systems 

Human  Engineering  Procedures  Guide 

Work  Breakdown  Structure  for  Defense  Materiel  Items 

System  Safety  Program  Requirements 
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MIL-STD-961C 

DoD-STD-963 

MIL-STD-970 


MIL-D-1000 
MIL-STD-1290 
MIL-STD-1294 
MIL-STD- 1 379D 
MIL-STD-1388-1A 
MIL-STD- 1 3 88-2B 
MIL-STD- 1425 

MIL-STD- 1456(MU) 
MIL-STD- 1472D 

MIL-STD- 1474 
MIL-STD-1512 

MIL-STD-1521 

MIL-STD-1567 
MIL-STD- 1662 
MIL-STD-1751 
MIL-STD- 1800 

MIL-STD- 1801 

MIL-STD-2165 

MIL-Q-9858 

MIL-I-23659 

MIL-T-23991 

MIL-H-46855B 

MIL-S-52779 
MIL-HDBK-6303 8-1 
MIL-HDBK-63038-2 
MIL-S-83490 


Military  Specifications  and  Associated  Documents,  Preparation  of 
Military  Standard:  Data  Item  Description  (DID),  Preparation  of 
Standards  and  Specifications,  Order  of  Preference  for  the  Selection 
of 

Drawings,  Engineering  and  Associated  Lists 

Light  Fixed  and  Rotary-Wing  Aircraft  Crashworthiness 

Acoustical  Noise  Limits  in  Helicopters 

Military  Training  Programs 

Logistic  Support  Analysis 

DoD  Requirements  for  a  Logistic  Support  Analysis  Record 
Safety  Design  Requirements  for  Military  Lasers  and  Associated 
Support  Equipment 

Contractor  Configuration  Management  Plans 
Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  and  Facilities 
Noise  Limits  for  Army  Materiel 

Electronic  Explosive  Subsystems,  Electrically  Initiated  Designs, 
Requirements  and  Test  Methods 

Technical  Reviews  and  Audits  for  Systems,  Equipments,  and 

Computer  Software 

Work  Measurements 

Equipment  and  Computer  Programs 

Safety  and  Performance  Tests  for  Qualification  of  Explosives 
Human  Factors  Engineering  Performance  Requirements  for 
Systems 

User-Computer  Interface 

Testability  Program  for  Electronic  Systems  and  Equipment 

Quality  Program  Requirements 

Initiator,  Electric,  General  Design  Specifications 

Training  Devices,  Military,  General  Specifications  for 

Human  Engineering  Requirements  for  Military  Systems, 

Equipment,  and  Facilities 

Software  Quality  Assurance  Program  Requirements 
Technical  Manuals  Writing  Handbook 
Technical  Writing  Style  Guide 
Specifications,  Types  and  Forms 


Directives/Instructions 


DoDD  1322.18 
DoDD  1430.13 
DoDD  4210.15 
DoDD  5000.1 
DoDD  5000.4 
DoDD  5000.49 


Military  Training 

Training  Simulators  and  Devices 

Hazardous  Material  Pollution 

Major  System  Acquisition 

OSD  Cost  Analysis  Improvement  Group 

Defense  Acquisition  Board 


AA-2 


DoDI  4151.12 

Policies  Governing  Maintenance  Engineering  Within  DoD 

DoDI  5000.2 

Major  System  Acquisition  Procedures 

DoDI  6050.5 

Hazard  Communication  Program 

DoDI  7041.3 

Economic  Analysis  and  Program  Evaluation  for  Resource 
Management 

OMB  Circular  No.  A- 109 

Major  System  Acquisitions 

ASTM  F  1166-88 

Standard  Practice  for  Human  Engineering  Design  for  Marine 
Systems,  Equipment  and  Facilities 

Army  MANPRINT  Regulations 

AR  15-14 

Systems  Acquisition  Review  Council  Procedures 

AR  25-400-2 

The  Modem  Army  Recordkeeping  System  (MARKS) 

AR  40-5 

Health  and  Environment 

AR  40-10 

Health  Hazard  Assessment  Program  in  Support  of  the  Army 
Materiel  Acquisition  Decision  Process 

AR  40-14 

Control  and  Recording  Procedures  for  Exposure  to  Ionizing 
Radiation  and  Radioactive  Materials 

AR  40-46 

Control  of  Health  Hazards  from  Lasers  and  Other  High  Intensity 
Optical  Sources 

AR  40-501 

Standards  of  Medical  Fitness 

AR  40-583 

Control  of  Potential  Hazards  to  Health  from  Microwave  and  Radio 
Frequency  Radiation 

AR  70-1 

System  Acquisition  Policy  and  Procedures 

AR  70-8 

Personnel  Performance  and  Training  Program  (PPTP) 

AR  70-10 

Test  and  Evaluation  During  Development  and  Acquisition  of 
Materiel 

AR  70-15 

Product  Improvement  of  Materiel 

AR  70-17 

System/Program/Proj  ect/Product  Management 

AR  70-25 

Use  of  Volunteers  as  Subjects  of  Research 

AR  71-2 

Basis  of  Issue  Plans  (BOIP),  Qualitative  and  Quantitative  Personnel 
Requirements  Information  (QQPRI) 

AR  71-3 

User  Testing 

AR  71-9 

Materiel  Objectives  and  Requirements 

AR  350-35 

Army  Modernization  Training 

AR  350-38 

Training  Device  Policies  and  Management 

AR  381-11 

Threat  Support  to  U.S.  Army  Force,  Combat  and  Materiel 
Development 

AR  385-9 

Safety  Requirements  for  Military  Lasers 

AR  385-10 

Army  Safety  Program 

AR  385-11 

Ionizing  Radiation  Protection,  Licensing,  Control,  Transportation, 
Disposal,  and  Radiation  Safety 

AMC  PAM  602-1 

MANPRINT  Handbook  for  RFP  Development  -  2nd  Edition 
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AR  385-16 
AR  385-30 
AR  385-32 
AR  385-61 

AR  385-64 
AR  570-1 

AR  570-2 

AR  570-4 
AR  570-5 
AR  602-1 
AR  602-2 
AR  611-101 
AR  611-112 
AR  611-201 

AR  680-29 
AR  700-70 

AR  700-86 
AR  700-127 
AR  700-129 

AR  702-3 

AR  702-9 
AR  750-1 

AR  750-37 

AR  1000-1 

DA  PAM  11-25 
DA  PAM  700-127 

AMCR  70-52 
AMCR  385-3 

AMCR  385-16 
AMCR  385-21 
AMCR  385-29 

SD-1 


System  Safety  Engineering  and  Management 
Safety  Color  Code  Marking  and  Equipment 
Protective  Clothing  and  Equipment 

Safety  Studies  and  Reviews  of  Chemical  Agents  and  Associated 
Weapon  Systems 

Ammunition  and  Explosive  Safety  Standards 

Manpower  and  Equipment  Control-Commissioned  Officer  Position 

Criteria 

Manpower  and  Equipment  Control— Manpower  Requirement 

Criteria  (MARC)  Table  of  Organization  and  Equipment 

Manpower  Management 

Manpower  Staffing  Standards  System 

Human  Factors  Engineering  Program 

Manpower  and  Personnel  Integration  (MANPRINT) 

Commissioned  Officer  Specialty  Classification  System 

Manual  of  Warrant  Officer  Military  Occupational  Specialties 

Enlisted  Career  Management  Fields  and  Military  Occupational 

Specialties 

Military  Personnel,  Organization  and  Types  of  Transaction  Codes 
Application  of  Specifications,  Standards  and  Related  Documents  in 
the  Acquisition  Process 

Life  Cycle  Management  of  Clothing  and  Individual  Equipment 
Integrated  Logistics  Support 

Management  and  Evaluation  of  Integrated  Logistics  Support 
Program  for  Multi-Service  Acquisitions 

Army  Materiel  Systems  Reliability,  Availability,  and 
Maintainability  (RAM) 

Production  Testing  of  Army  Materiel 

Army  Materiel  Maintenance  Policy  and  Retail  Maintenance 
Operation 

Sample  Data  Collection:  The  Army  Maintenance  Management 
System 

Basic  Policies  For  Systems  Acquisition 

Life  Cycle  System  Management  Model  for  Army  Systems 
Integrated  Logistics  Support  Managers  Guide 

System  Engineering 

Hazard  Analysis  of  Facilities,  Equipment  and  Process 
Developments 

System  Safety  Engineering  and  Management  Guide 
Determination  and  Assignment  of  AMC  Hazard  Classification 
Laser  Safety 

Standardization  Directory 
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AMC  PAM  602-1  MANPRINT  Handbook  for  RFP  Development  -  2nd  Edition 

AMC  PAM  602-2  MANPRINT  Handbook  for  Nondevelopmental  Item  (NDI) 

Acquisitions 

AMC  PAM  700-21  Integrated  Logistic  System  Contracting  Guide 

AMC  PAM  715-3  The  Source  Selection  Process,  Vols.  I,  n,  HI 

AMC  TRADOC  PAM  70-2  Materiel  Acquisition  Handbook 

TRADOC  PAM  350-30  Interservice  Procedures  for  Instructional  Development 

Aeronautical  Design  Human  Engineering  Requirements  for  Measurement  of  Operator 

Standards  ADS-30  Workload 


MANPRINT  Procedural  References 

MANPRINT  Practitioners  Guide  -  ODCSPER 
MANPRINT  Handbook  for  Source  Selection  -  ODCSPER 
Catalogue  of  MANPRINT  Methods  -  USA  Research  Institute 
MANPRINT  Risk  Assessment  -  USA  Soldier  Support  Center 

System  MANPRINT  Management  Plan  (SMMP)  Procedural  Guide  -  USA  Soldier  Support 
Center 

Early  Comparability  Analysis  (ECA)  Procedural  Guide  -  USA  Soldier  Support  Center 
MANPRINT  Database  User’s  Handbook  -  USA  Materiel  Command 


Naw  HARDMAN  and  Other  HSI  Instructions 


SECNAV  Instructions 


5000.2A 

5000.39  (series) 

5090.6  (series) 

5312.10  (series) 
7000.14  (series) 


Defense  Acquisition  Management  Policies  and  Procedures, 
Implementation  of 

Acquisition  and  Management  of  Integrated  Logistic  Support  for 
Systems  and  Equipment 

Evaluation  of  Environmental  Effects  from  Department  of  the  Navy 
Actions 

Manpower  Planning  Systems 

Economic  Analysis  and  Program  Evaluation  for  Navy  Resource 
Management 


OPNAV  Instructions 

1000.16  (series)  Manual  of  Navy  Total  Force  Manpower;  Promulgation  of 

1500.2  (series)  Responsibilities  and  Procedures  for  Establishment  and  Coordination 

of  Contractor  Developed  Training  for  Military  and  Civilian 
Personnel 
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1500.8  (series) 
1500.11  (series) 

1500. 19  (series) 

1500.27  (series) 
1500.44  (series) 

1500.51  (series) 

1500.52  (series) 

1540.2  (series) 

1541.4  (series) 

1543.49  (series) 

1550.6  (series) 

1550.8  (series) 

3500.23  (series) 

3500.34  (series) 
3960. 10  (series) 

4490.2  (series) 

4700.24  (series) 
4950.1  (series) 
5000.42  (series) 

5000.49  (series) 

5000.50  (series) 

5310.18  (series) 

5311.7  (series) 

7000.18  (series) 
9010.300  (series) 
1 1010.20  (series) 


Navy  Training  Planning  Process  in  Support  of  New  Developments 
Naval  Aviation  Training  Program  Policies,  Responsibilities  and 
Procedures 

Authority  and  Responsibility  of  Fleet  CINCs  for  Naval  Training 
Activities  Ashore 

Interservice  Education  and  Training 

Responsibilities  for  Development  of  Personnel  Training 
Requirements  and  Related  Plans 
Navy  Training  Strategy 

Surface  Warfare  Training  System  Policy,  Organization  and 
Responsibilities 

Naval  Air  Maintenance  Training  Program;  Policies  and  Procedures 
for 

Shipyard  Technical  Training  for  Fleet  Personnel;  Policy  for 
Technical  Training  Equipment  (TTE) 

Review  of  Navy  Formal  School  Curricula  and  Instructional 
Literature 

Development,  Review,  and  Approval  of  New  or  Modified  Training 
Course  Curricula 

Assembly,  Organization  and  Training  of  Crews  for  U.S.  Navy 
Ships  Commissioned  in  Time  of  Peace 
Personnel  Qualification  Standards  (PQS)  Program 
Test  and  Evaluation 

Availability  of  Operational  Equipment  and  Technical  Manuals  for 
Training  Purposes 

Policies  Governing  Maintenance  Engineering  within  the  DoD 

DoN  Security  Assistance  Training 

Research,  Development  and  Acquisition  Procedures 

Integrated  Logistic  Support  in  the  Acquisition  Process 

Navy  Training  Simulator  and  Device  Acquisition  and  Management 

Ship  Manpower  Document/Squadron  Manpower  Document 

(SD/SQMD)  Development  and  Review  Procedures 

Determining  Manpower,  Personnel  and  Training  (MPT) 

Requirements  for  Navy  Acquisitions  (HARDMAN  Program) 

Economic  Analysis  and  Program  Evaluation  for  Navy  Resoruce 

Management 

Top  Level  Requirements  and  Top  Level  Specifications  for  the 
Development  of  Naval  Ships 
Facilities  Projects  Manual 
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Other  Naw  Instructions 

Naval  Facilities  Engineering  Command  (NAVFAQ  Instructions 

11010.14  (series)  Project  Engineering  Documentation  (PED)  for  Proposed  Military 

Construction  Projects 

11010.44  (series)  Shore  Facilities  Planning  Manual 


Chief  of  Naval  Education  and  Training  (CNET)  Instructions 


1500.9  (series) 

1500.12  (series) 
5311.1  (series) 


Participation  by  the  Naval  Education  and  Training  Command  in  the 
Preparation  and  Implementation  of  Navy  Training  Plans 
Glossary  of  Naval  Education  and  Training  Terminology 
Specialized  Training  Staffing  Requirements 


Naval  Air  Systems  Command  (NAVAIR1 

3900. 10  (series)  Lead  System  Command  Policy  for  Human  Factors 


Naval  Sea  Systems  Command  (NAVSEA1 

3900.8  (series)  Human  Factors  in  the  Naval  Sea  Systems  Command 


Miscellaneous  Documents 


NAVEDTRA  10500 
OPNAV  90P 
NAVFAC  P-80 

NAVPERS  18068  (series) 

NAVPERS  15839  (series) 
NAVTRADEV  P-530-2 


Catalogue  of  Navy  Training  Courses  (CANTRAC) 

Department  of  the  Navy  Programming  Manual 

Facilities  Planning  Factor  Criteria  for  Navy  and  Marine  Corps 

Shore  Installations 

Manual  of  Navy  Enlisted  Manpower  and  Personnel  Classifications 
and  Occupational  Standards 

Manual  of  Navy  Officer  Manpower  and  Personnel  Qualifications 
Training  Equipment  Guide 


Navy  (OPNAV't  HARDMAN  Documentation 

P-111-13-85  The  Program  Manager’s  MPT  Advisory  Board  Guide 

P-111-11-85  HARDMAN  Aviation  MPT  Resource  Requirements  Document 

Review  Guide 

P-111-10-85  HARDMAN  Aviation  MPT  Concept  Review  Guide 
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P-1 11-9-85 

P-111-8-85 

P-111-4-85 

P-111-3-85 

P-111-2-85 

P-111-1-85 


HARDMAN  E/S/S  MPT  Resource  Requirements  Document 
Review  Guide 

HARDMAN  E/S/S  MPT  Concept  Document  Review  Guide 
MPT  Data  Sources  Directory:  Analyst’s  Guide 
HARDMAN  Methodology:  Total  Ship 
HARDMAN  Methodology:  Aviation 
HARDMAN  Methodology:  Equipment/System/Subsystem 
Total  Ship  Preliminary  Manpower  Report  Review  Guide 
HARDMAN  Training  Workshop  Instructor’s  and  Participant’s 
Manual  (available  for  E/S/S  and  Aviation  versions) 
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APPENDIX  B 


ADM 

AFQT 

AP 

ASVAB 

BCM 

BCS 

CBA 

CCB 

CDRL 

CGTP 

CM 

CO 

CPS 

DCNO 

DCNO(MPT) 

DCSPR 

DID 

DISC 

DMSO 

DoD 

DoT 

EA 

ECP 

EMDM 

EMR 

EPA 

EPR 

E/S/S 

FEA 

FM 

FRS 


LIST  OF  ACRONYMS 


Advanced  Development  Model 
Armed  Forces  Qualification  Test 
Acquisition  Plan 

Armed  Forces  Vocational  Aptitude  Battery 

Baseline  Comparison  Model 
Baseline  Comparison  System 

Cost  Benefit  Analysis 
Configuration  Control  Board 
Contract  Data  Requirements  List 
Coast  Guard  Training  Plan 
Corrective  Maintenance 
Chief  of  Naval  Operations 
Contractor  Plan  Services 

Deputy  Chief  of  Naval  Operations 

Deputy  Chief  of  Naval  Operations  for  Manpower,  Personnel 
and  Training 

Deputy  Chief  of  Staff  for  Personnel  (Army) 

Data  Item  Description 

Command,  Control,  Communications,  Computers  (Army) 
Director,  Major  Staff  Office  (Navy) 

Department  of  Defense 
Department  of  Transportation 

Evolutionary  Acquisition 

Engineering  Change  Proposal 

Enhanced  Manpower  Determination  Model 

Enlisted  Master  Record 

Environment  Protection  Agency 

Equipment  Facility  Report 

Equipment/Systems/Subsystem 

Front-End  Analysis 

Facility  Maintenance 

Fleet  Replacement  Squadron  (Navy) 
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G-CPA 

Programs  Division,  Chief  of  Staff  Office 

GFE 

Government  Furnished  Equipment 

G-P 

Office  of  Personnel  and  Training 

HARDMAN 

Military  Hardware/Manpower  Integration  (Navy) 

HEPP 

Human  Engineering  Program  Plan 

HFE 

Human  Factors  Engineering 

HHPP 

Health  Hazard  Program  Plan 

HIS 

HARDMAN  Information  System 

HSI 

Human  Systems  Integration 

HSUWG 

HSI  Joint  Working  Group 

HSISMP 

Human  Systems  Integration  System  Management  Plan 

IEM 

Initial  Estimate  of  Manpower 

ILS 

Integrated  Logistics  Support 

ILSP 

Integrated  Logistics  Support  Plan 

IMPACTS 

Integrated  Manpower,  Personnel,  and  Comprehensive  Training 
and  Safety  (Air  Force) 

ISD 

Instructional  System  Development 

JMSNS 

Justification  for  Major  System  New  Start 

KDP 

Key  Decision  Point 

KSA 

Knowledge,  Skills,  and  Abilities 

LCC 

Life-Cycle  Cost 

LCCE 

Life-Cycle  Cost  Estimate 

LSA 

Logistics  Support  Analysis 

MANPRINT 

Manpower  and  Personnel  Integration  (Army) 

MAPTIDES 

Manpower,  Personnel  and  Training  Integration  in  the  Design 
of  Systems 

MCP 

Materiel  Change  Packages 

MIL-STD 

Military  Standard 

MJWG 

MANPRINT  Joint  Working  Group 

MNS 

Mission  Need  Statement 

MPT 

Manpower,  Personnel,  and  Training 

MPTCD 

Manpower,  Personnel,  and  Training  Concept  Document 

MPTRRD 

Manpower,  Personnel,  and  Training  Resource  Requirement 
Document 
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NATO 

North  Atlantic  Treaty  Organization 

NAVAIR 

Naval  Air  Systems  Command 

NAVMAC 

Navy  Manpower  Analysis  Center 

NAVSEA 

Naval  Sea  Systems  Command 

NDI 

Non-Developmental  Item 

NMRS 

Navy  Manpower  Requirements  System 

NTP 

Navy  Training  Plan 

NTPC 

Navy  Training  Plan  Conference 

OBT 

Onboard  Training 

OHSIP 

Office  Responsible  for  the  Human  Systems  Integration 
Program 

OJT 

On-the-Job  Training 

OLSP 

Operational  Logistics  Support  Plan 

OM 

Operational  Manning 

OPNAV 

Office  of  the  Chief  of  Naval  Operations 

ORD 

Operational  Requirements  Document 

OSHA 

Occupational  Safety  and  Health  Administration 

OUS 

Own  Unit  Support 

PAL 

Personnel  Allowance  List 

PHA 

Preliminary  Hazard  Analysis 

PLM 

Planned  Maintenance 

PM 

Program/Project  Manager 

PMP 

Project  Management  Plan 

PMR 

Preliminary  Manpower  Report 

POE 

Projected  Operating  Environment 

POM 

Program  Objective  Memorandum 

PORD 

Preliminary  Operational  Requirements  Document 

PS 

Program  Sponsor 

PSQMD 

Preliminary  Squadron  Manpower  Document 

PVMD 

Preliminary  Vessel  Manpower  Document 

RAMPARTS 

Manpower,  Personnel,  and  Requisite  Training  and  Safety  (Air 
Force) 

RFP 

Request  for  Proposals 

ROC 

Required  Operational  Capability 

RS 

Resource  Sponsor 
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SECNAV 

Secretary  of  the  Navy 

SHA 

System  Hazard  Analysis 

SMD 

Ship  Manpower  Document 

SMMP 

System  MANPRINT  Management  Plan 

SQMD 

Squadron  Manpower  Document 

SSE 

System  Safety  Engineering  Office 

SSEB 

Source  Selection  Evaluation  Board 

SSHA 

Subsystem  Hazard  Analysis 

SS/HH 

System  Safety/Health  Hazards 

SSPP 

System  Safety  Program  Plan 

SYSCOM 

Systems  Command  (Navy) 

TAD 

Target  Audience  Description 

T&E 

Test  and  Evaluation 

TEMP 

Test  and  Evaluation  Master  Plan 

TTWG 

Test  Integration  Working  Group 

TOA 

Trade-off  Analysis 

WSR 

Work  Station  Requirement 
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DESCRIPTION  OF  ARMY  MANPRINT  PROGRAM 


Governed  by  Army  Regulation  602-2  titled  Manpower  and  Personnel  Integration 
(MANPRINT)  in  Material  Acquisition  Process 

MANPRINT  includes  six  domains 

a.  Human  Factors  Engineering 

b.  System  Safety 

c.  Health  Hazards 

d.  Manpower 

e.  Personnel 

f.  Training 

Deputy  Chief  of  Staff  for  Personnel  (DCSPER)  has  policy  responsibility  for  the  program 

Two  subordinate  Major  Army  Commands  have  primary  responsibility  for  implementing 
the  MANPRINT  Program 

a.  Training  and  Doctrine  Command  (TRADOC) 

(1)  Responsible  for  MANPRINT  requirements 

(2)  Has  published  numerous  procedural  guides 

b.  Army  Material  Command  (AMC)— Responsible  for  system  design  and 
development 

(1)  Translates  Combat  Developers  MANPRINT  goals  and  constraints  into 
system  specifications  and  solicitation  documents 

(2)  Has  published  a  number  of  handbooks  on  how  to  include  MANPRINT  in 
system  design  and  development 

MANPRINT  goals 

a.  Improve  system  performance 

b.  Improve  manpower  and  personnel  utilization 

c.  Improve  unit  effectiveness 

Scope  of  MANPRINT  Program 


a.  Developmental 


b.  Non-developmental 

c.  Material  change  programs 

d.  Nonstandard  commercial  equipment  items 

Designed  primarily  as  a  bottoms-up  approach  to  answer  the  question  "Can  this  soldier, 
with  this  training  and  equipment,  perform  these  tasks  to  these  standards  under  these 
conditions" 

MANPRINT  seeks  to  optimize  total  system  performance  by  considering  the  soldier  as 
an  integral  part  of  the  material  system — This  total  system  includes  three  components: 
equipment,  environment,  and  soldier 

a.  Equipment— Hardware  and  software—  Including  factors  that  affect  equipment 
variability  (e.g.,  reliability,  redundancy,  accuracy,  and  safety)  that  impact  soldier 
performance  and  can  be  designed  to  complement  the  soldier 

b.  Environment  Including  variables  such  as  isolation,  heat,  noise,  weather, 

continuous  operations,  battlefield  environment  including  nuclear,  biological,  and 
chemical  (NBC)  warfare  and  fear,  and  organizational  structure  in  which  the 
system  must  operate— Environment  is  a  consideration  when  assessing  the  ability 
of  the  soldier  to  perform  as  part  of  the  total  system 

c.  Soldier— Trained  operators,  maintainers,  and  support  personnel— Soldier 
performance  variables  parallel  the  domains  of  MANPRINT,  including  numbers 
(manpower),  quality  (personnel),  skills  (a  combination  of  aptitude  and  training), 
soldier- machine  interface  (human  factors),  and  risks  (safety  and  health 
hazards)  These  variables  must  be  consistent  with  those  in  equipment  and 
environment  in  choosing  among  design  alternatives. 

MANPRINT  Process  Specific  actions  that  must  be  accomplished  to  ensure  that  soldier 
performance  issues  are  identified,  addressed,  and  managed  throughout  the  design, 
development,  and  acquisition  of  a  new  material  system 

a.  Identification  of  a  materiel  need 

b.  Front-End  Analysis  to  provide  information  needed  to  resolve  MANPRINT  issues 
and  include  MANPRINT  criteria  in  program  documentation 

c.  Formation  of  a  MANPRINT  Joint  Working  Group 

d.  Development  of  a  System  MANPRINT  Management  Plan  (SMMP)  to  manage 
these  issues— Including  identification  of  the  Target  Audience  Description  (TAD) 

e.  Documentation  of  total  system  performance  requirements  and  specifications, 
including: 
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(1) 

(2) 

(3) 


MANPRINT  constraints 
MANPRINT  assessment 
Test  and  Evaluation  Master  Plan  (TEMP) 


10.  MANPRINT  Responsibilities  in  individual  acquisitions 

a.  Combat  Developer— Identifies  a  battlefield  deficiency  that  cannot  be  resolved  with 
a  change  in  doctrine,  training,  or  organization 

(1)  Performs  early  studies  and  analysis  to  determine  initial  MANPRINT 
requirements 

(2)  Represents  user  member  and  co-chair  of  MJWG 

(3)  Performs  MANPRINT  assessments  in  conjunction  with  Material 
Developer  for  smaller  acquisitions 

b.  Material  Developer— Translates  Combat  Developer’s  MANPRINT  goals  and 
constraints  into  system  specifications  and  solicitation  documents 

(1)  Member  and  co-chair  of  MJWG 

(2)  Conducts  analysis  and  produces  reports  and  plans  in  support  of  SMMP 
soldier  performance  information  requirements,  including  the  following: 

(a)  Human  Factors  Engineering  Assessment  (HFEA) 

(b)  Safety  Assessment  Report  (SAR) 

(c)  Test  and  Evaluation  Master  Plan  (TEMP) 

(d)  Integrated  Logistic  Support  Plan  (ILSP) 

c.  Program  Executive  Officer/Program  Manager  (PEO/PM) 

(1)  Has  overall  management  and  decision  authority  for  a  program 

(2)  Considered  MANPRINT  requirements  when  establishing  cost,  scheduling, 
and  performance  baselines 

(3)  Industries  responsiveness  to  MANPRINT  issues  is  based  largely  on 
perception  of  MANPRINT’ s  importance  to  PEO/PM 

1 1 .  Membership  of  MJWG— Membership  is  tailored  based  on  soldier  performance  issues  of 
the  system— Can  be  altered  as  new  issues  are  identified 

a.  Combat  Developer — Convenes  and  chairs  MJWG  prior  to  Milestone  1 — AT 
Milestone  1  and  beyond  the  Combat  Developer  and  Material  Developer  co-chair 
the  MJWG 
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b.  Material  Developer— Transitions  program  management  responsibilities  to 

PEO/PM  at  Milestone  1 

c.  Trainer  Developer 

d.  Manpower/Personnel  Proponent 

e.  Director  of  Standardization  and  Evaluation 

f.  Safety  Office 

g.  PM 

h.  May  also  have  following  members 

(1)  Army  Research  Institute 

(2)  Human  Engineering  Laboratory 

(3)  Test  and  Evaluation  Community 

(4)  Other  supporting  TRADOC  schools 

12.  Development  of  System  MANPRINT  Management  Plan 

a.  Army  developed  SMMP  to  resolve  two  critical  weaknesses  in  the  acquisition 
management  process: 

(1)  Neither  program  nor  requirements  documents  provided  insight  to  what 
soldier  can  and  cannot  do 

(2)  The  impact  of  fielding  a  new  system  on  the  soldier  was  not  controlled 
because  of  insufficient  management  visibility 

b.  SMMP  is  the  sole-source  MANPRINT  document 

(1)  Serves  as  a  planning  and  management  guide 

(2)  Provides  an  audit  trail  to  track  MANPRINT  issues  and  concerns  prior  to 
and  throughout  development  and  fielding  of  a  new  system 

(3)  Identifies  the  MANPRINT— related  tasks,  analysis,  trade-offs,  and 
decisions  that  are  affected  during  the  material  acquisition  process 

c.  SMMP  is  structured  in  five  sections 

(1)  Section  1  —  Executive  Summary 

(2)  Section  2  —  System  Description 
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(3)  Section  3  —  MANPRINT  Strategy  —  Objectives  and  strategy  to  achieve 
objectives 

(4)  Section  4  —  Critical  Issues  —  Defines  major  risk  areas 

(5)  Section  5  —  Tabs 
Tab  A  -  Data  Sources 

Tab  B  -  System  and  MANPRINT  Milestone  Schedule 

Tab  C  -  Task  Description 

Tab  D  -  MANPRINT  Major  Issues/Concems 

Tab  E  -  Coordination 

Tab  F  -  Audit  Trail 

Tab  G  -  Target  Audience  Description 

Tab  H  -  Lessons  Learned  and  Deficiencies  of  Predecessor  System 

d.  SMMP  Initiation  and  Approval 

(1)  The  Combat  Developer  of  the  Training  Developer  will  initiate  the  SMMP 
after  a  battlefield  deficiency  has  been  identified  that  requires  a  new  or 
improved  material  system 

(2)  The  Combat  or  Training  Developer  remains  the  lead  for  SMMP  but  the 
MJWG  provides  assistance  in  addressing  domain  specific  issues 

(3)  The  SMMP  is  jointly  approved  by  the  Combat  Developer  (the  initiating 
agency  and  user  representative)  and  the  Army  Material  Command  (the 
implementing  agency  and  material  developer)  30  days  prior  to  each 
milestone  decision  review 

e.  SMMP  Emphasis 

(1)  Pre  Milestone  1:  Focuses  on  influencing  design  —  Emphasis  is  on 
identifying  existing  guidance,  predecessor  and  comparable  systems,  data 
sources,  areas  of  concern,  and  analysis  that  will  be  required 

(2)  Post  Milestone  1:  Focuses  on  system’s  operational  supportability  from  a 
manpower,  personnel  and  training  perspective;  resolution  of  issues;  and 
integration  of  soldier  performance  issues  in  other  program  documents  to 
achieve  system  MANPRINT  objectives 

f.  MANPRINT  Information  Categories  —  SMMP  manages  the  overall  MANPRINT 

effort,  which  includes  plans  for  identifying,  collecting,  evaluating,  and  applying 

information  to  influence  design  and  system  selection 

(1)  MANPRINT  Information  is  included  in  five  main  categories 
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(a)  Deficiency  Information/Performance  Requirements  —  What  aspects 
of  the  predecessor  system  need  to  be  improved? 

(b)  Program  Guidance  —  What  decisions  have  been  made  that  impact 
resources  (e.g.,  manpower,  personnel,  or  training  base  resources)? 

(c)  Lessons  Learned  —  What  have  we  learned  in  designing  and 
operating  previous  systems  that  we  want  to  improve  in  a  new 
system? 

(d)  Prediction  —  Have  the  abilities  and  limitations  of  the  future  soldier 
been  considered  when  determining  the  total  system  performance 
requirements  of  the  new  system? 

(e)  Assessment  —  Have  key  information  source  documents  and 
analysis  been  completed  adequately?  Are  there  unresolved 
MANPRINT  issues  that  need  to  be  addressed? 

13.  Front-End  Analyses  (FEA)  —  Influences  design  or  system  requirements  and  may  impact 
alternative  concept  selections  by  identifying  MANPRINT  constraints,  Limitations,  and 
objectives 

a.  Includes  analyses  of  the  following  Mission  and  Support  System  Definition  tasks: 

(1)  Task  1  Use  study  —  Identifies  and  documents  pertinent  supportability 
factors  of  the  proposed  system 

(2)  Task  2  Mission  Hardware,  Software,  and  Support  System  Standardization 
—  Defines  design  constraints  of  proposed  system  based  on  existing  and 
planned  logistic  support  resoruces  —  Also  provides  supportability  input  to 
mission  hardware  and  software  standardization  efforts 

(3)  Task  3  Comparative  Analysis  —  Develops  a  baseline  comparison  system 
representing  the  characteristics  of  the  proposed  equipment 

(4)  Task  4  Technological  Opportunities  —  Identifies  technological 
advancements  and  state-of-the-art  design  approaches  which  offer 
opportunities  for  achieving  improvements  in  the  new  system 

(5)  Task  5  Supportability  and  Supportability-Related  Design  Factors 

14.  MANPRINT  Reviews  and  Assessments 

a.  Reviews  —  Conducted  to  determine  status  and  adequacy  of  MANPRINT  efforts 

(1)  Normally  held  in  conjunction  with  ILS  Management  Team  reviews 
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(2)  Program  Sponsor/PM  responsible  for  reviews 

(3)  Results  are  documented  in  appropriate  program  decision  documents 
b.  Assessments  —  Conducted  prior  to  each  milestone  decision  review 

(1)  Determine  status  and  adequacy  of  MANPRINT  efforts  and  presents  any 
unresolved  MANPRINT  issues  or  concerns  to  decision  makers 

(2)  For  major  programs,  DCSPER  conducts  assessment  —  AMC,  TRADOC 
or  other  designated  MACOM  conducts  assessment  for  non-major  programs 

15.  Test  and  Evaluation  —  Observes  system  performance  during  acquisition  process 

a.  MANPRINT  looks  beyond  individual  domain  issues  to  test  and  evaluate  system’ s 
total  operational  capability 

b.  Testing  is  tailored  by  Test  Integration  Working  Group 

c.  MANPRINT  T&E  includes  following  types  of  testing  (tailored  by  TIWG  to  fit 
requirements  of  each  acquisition) 


(1) 

Prototype  and  Surrogate  Testing 

(a) 

Force  Development  T&E 

<b) 

Concept  Evaluation 

(c) 

Technical  Feasibility  Testing 

(d) 

Operational  Feasibility  Testing 

(2) 

Component  Level  Testing 

(a) 

Developmental  Testing 

(b) 

Early  User  Test  and  Evaluation 

(3) 

Full  Scale  Testing 

(a) 

Preproduction  Testing 

(b) 

Initial  Operational  T&E  (IOT&E) 

(c) 

Preproduction  Qualification  Testing 

(d) 

Live  Fire  T&E  (Combat  Systems) 

(4) 

Production  &  Deployment/Operational  Testing 

(a) 

Production  Qualification  Testing 

(b) 

Follow-on  T&E 
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Test  and  Evaluation  Master  Plan  (TEMP)  -  Planning  document  that  identifies 
critical  technical  and  operational  issues  as  well  as  all  planned  test  activities 

(1)  TEMP  is  prepared  by  TIWG  and  provides  interface  between  TIWG  and 
other  Army  activities  conducting  testing 

(2)  Test  issues  and  criteria  are  jointly  developed  by  the  TIWG  and  MJWG 

(3)  If  an  issue  is  not  planned  for  testing  in  TEMP  it  probably  will  not  be 
tested 

MANPRINT  includes  three  other  test-related  documents 

(1)  Technical  Independent  Evaluation  Plan  -  Addresses  safety,  health,  and 
Human  Factors  Engineering  issues 

(2)  Operational  Independent  Evaluation  Plan  —  Focuses  on  soldier 
performance  issues 

(3)  Test  Design  Plan  —  Describes  conditions  and  standards  for  required 
testing 

(a)  How  and  when  will  test  be  conducted  —  Operational  environment 

(b)  Number  and  quality  of  soldiers  to  be  used  —  Manpower  and 
personnel 

(c)  Test  player  preparation  program  —  Training 
MANPRINT  in  Life  Cycle  System  Management  Model  (LCSMM) 

(1)  Primary  objective  of  MANPRINT  is  to  influence  system  design  by 
considering  soldier  performance  as  an  integral  part  of  total  system 
operation 

(2)  This  MANPRINT  objective  is  achieved  by  integrating  MANPRINT 
considerations  and  constraints  into  the  program  management  documents 
that  drive  design  and  supportability  aspects  of  the  developing  system  in 
each  phase  of  LCSMM 

(3)  Standards  are  used  in  an  interactive  process  of  definition,  synthesis,  trade¬ 
off,  test,  and  evaluation  —  The  aim  is  to  achieve  the  best  balance  between 
cost,  schedule,  performance,  and  supportability 
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DESCRIPTION  OF  NAVY  HARDMAN,  PLUS  REMAINING  NAVY  HSI  PROGRAM 


1.  The  Navy  Hardware/Manpower  Integration  (HARDMAN)  Program  is  governed  by 
OPNAVINST  5311.7  titled  "Determining  MPT  Requirements  for  Navy  Acquisitions". 
The  HARDMAN  Program  includes  only  the  Manpower,  Personnel,  and  Training 
Domains. 

2.  SECNAVINST  5000.2A  titled  "Defense  Acquisition  Management  Policies  and 
Procedures,  Implementation  of"  is  a  new  instruction  (December  1992)  aimed  at 
implementing  the  DoD  HSI  Program  in  Navy  acquisition.  This  instruction  reaffirms  use 
of  the  HARDMAN  Program  to  determine  MPT  requirements  and  also  specifies  that 
Human  Factors  Engineering  and  System  Safety /Health  Hazard  Domains  will  be  included 
in  system  design  for  new  Navy  acquisitions. 

3.  The  Navy  realized  the  need  for  HFE  and  SS/HH  as  early  as  1983  when  the  Naval 
Materiel  Command  issued  NAVMATTNST  3900. 9 A  titled  "Human  Factors  in  the  Naval 
Materiel  Command."  This  instruction  required  Navy  Systems  Commands  to  use  all  the 
elements  of  the  current  DoD  HSI  Program  in  the  design  and  development  of  system 
acquisitions  (although  without  the  emphasis  on  integration  of  the  elements).  This 
prompted  each  Systems  Command  to  publish  their  own  instructions,  with  NAVSEA 
publishing  NAVSEAINST  3900.8  titled  "Human  Factors  in  the  Naval  Sea  Systems 
Command"  in  1984,  followed  in  1986  by  the  Naval  Air  Systems  Command  publishing 
NAVAIRINST  3900.10  titled  "Lead  System  Command  Policy  for  Human  Factors." 

4.  The  HARDMAN  Program  is  well  documented  down  to  the  analyst  level  of  detail. 
Appendix  A  includes  publications  supporting  the  HARDMAN  Program  and  other  Navy 
HSI  requirements. 

5.  Since  early  1992,  the  Navy  has  had  a  contractor  updating  most  of  the  HARDMAN 
publications.  In  discussions  with  the  contractor,  he  indicates  that  the  basic  steps  in  each 
methodology  has  not  changed,  but  the  data  collection  and  final  reports  are  being 
automated.  Some  procedural  changes  are  also  being  included. 

6.  Deputy  Chief  of  Naval  Operations  for  Manpower,  Personnel,  and  Training  (OP-01)  has 
policy  responsibility  for  the  HARDMAN  Program.  Navy  System  Commands  (through 
Program  Managers)  are  responsible  for  system  design,  development,  and  implementation 
of  HSI,  while  OP-01  reviews  and  approves  the  completed  draft  MPT  plans  for  Navy 
acquisitions.  No  single  organization  has  overall  responsibility  for  HSI  in  the  Navy.  This 
is  a  significant  weakness  compared  to  the  Army  MANPRINT  Program. 
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7.  The  HARDMAN  Methodology  is  an  iterative  process  designed  to  meet  the  following 
objectives: 

a.  Satisfy  MPT  planning  and  reporting  requirements  in  the  system  acquisition 
process,  particularly  during  the  pre-Milestone  I  period 

b.  Identify  critical  MPT  issues 

c.  Provide  early  estimates  of  MPT  requirements 

d.  Identify  high  MPT  drivers 

e.  Provide  manpower/hardware  trade-off  analysis  data 

f.  Integrate  MPT  requirements  into  the  system  design  and  decision-making  process 

g.  Develop  and  maintain  an  audit  trail  to  support  MPT  decisions  during  the 
acquisition  process 

h.  Establish  an  MPT  data  base  for  subsequent  development  of  system  acquisition 
documentation,  including  Navy  Training  Plans,  Integrated  Logistic  Support  Plans, 
and  other  manpower-related  documents  and  requirements 

8.  The  Navy  program  calls  for  the  following  manpower  planning  as  part  of  Integrated 
Logistic  Support: 

a.  Prior  to  Program  Initiation  fMilestone  Oi 

Manpower  resource  constraints  must  be  identified  in  the  Justification  for  Major 
System  New  Start.  If  appropriate,  these  constraints  should  be  based  on  an 
analysis  of  systems  currently  in  the  mission  area. 

b.  Prior  to  Milestone  I 

Manpower  implications  of  alternative  operational  and  support  concepts  must  be 
evaluated;  the  requirements  must  be  identified  and  determined  to  be  consistent 
with  updated  program  constraints.  Manpower  cost  drivers  of  current  systems 
must  be  identified  and  potential  for  improvement  established.  Manpower 
parameters  critical  to  system  readiness  must  also  be  identified. 

c.  Prior  to  Milestone  II 

A  consistent  set  of  manpower  goals  and  thresholds  must  be  established  and 
compared  to  a  baseline  system.  The  sensitivity  of  manpower  resource 
requirements  to  changes  in  key  parameters  and  the  associated  impacts  on 
readiness  must  be  analyzed.  Manpower  requirements  by  work  center  must  be 
identified  based  on  design,  support,  and  readiness  trade-off  analyses. 
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Requirements  for  unique  skills  or  specialties  which  are  in  short  supply  must  be 
identified. 

d.  Prior  to  Milestone  HI 

Manpower  requirements  must  be  validated  to  assure  goals  for  peacetime  readiness 
and  wartime  employment  are  met.  A  preliminary  manpower  document  and 
support  analysis  (including  comparison  by  work  center  to  a  baseline  system)  must 
be  available  and  manpower  requirements  must  be  satisfied  by  projected  assets. 

9.  The  following  are  principal  requirements  contained  in  the  HARDMAN  instruction 
(OPNAVINST  5311.7).  See  Exhibit  App  D-l  for  MPT  considerations  by  acquisition 
phase. 

a.  Establishment  of  an  MPT  Advisory  Board 

Early  in  program  development  an  informal  MPT  Advisory  Board  will  be  created 
and  established  formally  in  writing.  The  advisory  board  shall  provide  the  PM 
with  subject  matter  expert  (SME)  support,  review  and  evaluation,  and  assist  the 
PM  to  identify  and  address  MPT  issues. 

b.  Development  of  an  MPT  Concept  Document  (MPTCD!  prior  to  Milestone  I 

The  MPTCD  shall  identify  the  projected  use  of  manpower  to  satisfy  operator  and 
maintainer  requirements  and  training  requirements  for  the  new  system.  This 
document  will  be  prepared  by  the  Project  Management  Office  (PMO)  and 
forwarded  to  the  MPT  Advisory  Board  for  review  and  comment  prior  to 
Milestone  I. 

c.  Development  of  an  MPT  Resource  Requirements  Document  (MPTRRD!  prior  to 
Milestone  I 

The  MPTRRD  shall  identify  the  MPT  resources  necessary  to  support  the 
operation,  maintenance,  and  training  concepts  developed  in  the  MPTCD.  The 
first  iteration  of  the  MPTRRD  will  be  forwarded  to  the  MPT  Advisory  Board  in 
time  for  review  and  comment  prior  to  the  scheduled  Milestone  I  program  review. 
Following  this  review,  the  MPTRRD  will  be  updated  to  reflect  acquisition 
concept  changes  and  will  be  the  PM’s  statement  of  MPT  requirements  until  the 
draft  Navy  Training  Plan  (NTP)  is  approved. 

10.  The  Navy  Training  Plan  instruction,  OPNAVINST  1500.8  series  titled  "Navy  Training 
Planning  Process",  is  the  keystone  for  the  planning  of  Navy  training.  It  establishes 
policies,  procedures,  and  assigned  responsibilities  for  the  planning,  programming,  and 
implementing  actions  necessary  to  provide  manpower,  personnel,  and  training  support 
for  ships,  aircraft,  equipment,  systems,  subsystems,  and  non-hardware  oriented 
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developments.  It  also  provides  guidelines  to  ensure  coordination  of  billets,  personnel, 
military  construction,  training  support,  and  training  planning  concurrent  with  hardware 
development  and  production. 

The  HARDMAN  Methodology  was  designed  as  an  enhancement  to  the  NIP  process, 
initiating  the  MPT  planning  process  closer  to  the  beginning  of  the  acquisition  process. 
This  allows  for  the  production  of  training  planning  data  starting  in  the  pre-Milestone  I 
period.  By  doing  so,  HARDMAN  makes  possible  the  comparison  of  alternative  training 
concepts  and  the  early  formulation  of  the  training  plan  and  training  resource 
requirements.  Once  determined,  this  allows  ample  lead  time  to  program  for  and  acquire 
training  resources,  to  formulate  and  establish  the  training  program,  and  to  train  and  detail 
personnel.  Total  training  resource  requirements  to  establish  initial  and  follow-on  training 
capability  must  be  incorporated  in  the  planning,  programming,  and  budgeting  process 
early  during  hardware  development  and  made  increasingly  definitive  as  the  system 
development  progresses. 

The  key  participants  in  the  NIP  process  are  defined  in  OPNAVINST  1500.8  as  CNO, 
DCNO/DMSO  Program  Sponsor,  Resource  Sponsors,  SYSCOMs,  PMs  and  other 
Principal  Development  Activities  (PDA).  Exhibit  App  D-2  displays  a  flow  chart  of  the 
NIP  process  and  the  roles  of  its  major  participants. 
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Exhibit  App  D-2.  Navy  Training  Planning  Process  Flow  Chart 


APPENDIX  E 


HSI  SYSTEM  MANAGEMENT  PLAN 


Section  1  —  Executive  Summary.  Provides  an  overview  of  HSI  strategy  and  describes  highlights 
of  the  Plan.  HSI  objectives  and  requirements  are  related  to  readiness,  force  structure, 
affordability,  performance  effectiveness,  and  achievement  of  operational  objectives.  The  scope 
and  purpose  of  HSI  is  described,  as  is  a  summary  of  HSI  constraints  and  results  of  HSI  analyses 
and  trade-offs. 

Section  2  —  Description  of  the  New  Acquisition. 

1.  System  Description:  Defines  essential  total  system  performance  characteristics  and 
identifies  where  potential  man-machine  problem  areas  exist.  This  includes  the  following: 

a.  General  description  of  the  system  itself 

b.  Major  system  components  including  form,  fit,  and  function 

c.  Missions  to  be  performed 

d.  Operational  environments 

e.  Alternative  concepts  or  design 

f.  Essential  total  system  (human-in-the-loop)  performance  characteristics 

g.  Techniques  for  integrating  humans  into  the  system 

h.  Stage  of  system  development  at  the  time  of  HSISMP  publication 

2.  Acquisition  Strategy:  Description  of  proposed  or  approved  strategy  including 
determination  that  the  acquisition  is  a  new  development,  MIL-SPEC  procurement,  non- 
developmental  item  (NDI),  or  product  improvement.  Indicates  stage  of  development  or 
initial  acquisition  phase  if  it  is  a  new  system  development. 

3.  Activities  Involved:  This  includes  a  complete  list  of  all  Headquarters  Staff  Offices, 
Headquarters  Units,  and  other  activities  linked  to  HSI  for  this  project.  All  activities  are 
linked  to  the  HSI  Milestone  Schedule  in  Tab  B. 

4.  System  Acquisition  Milestones  and  Schedule:  Includes  due  dates  for  key  events  linked 
to  HSI  Milestone  Schedule  contained  in  Tab  B. 
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5.  Guidance:  Lists  decisions  made  that  will  impact  this  acquisition,  including  the  following: 

a.  Prior  decisions  by  Congress,  the  President,  DoT,  etc. 

b.  General  Coast  Guard  guidance 

c.  Assumptions 

d.  Mandated  constraints 

e.  Information  relating  to  future  personnel  characteristics  and  force  structure 

Section  3  —  HSI  Issues  and  Constraints.  This  section  identifies  key  issues  that  have  HSI 
implications,  including  constraints  established  in  MNS,  and  issues  in  major  design,  readiness, 
test  and  evaluation,  and  affordability.  The  requirement  to  document  the  management  and 
resolution  of  HSI  issues  during  the  acquisition  process  makes  the  HSISMP  a  "living  document" 
and  establishes  the  requirement  for  an  audit  trail  or  program  history.  Section  3  includes  the 
following  specific  areas: 

1.  Personnel  Constraints 

a.  End  strength  limitations 

b.  Budget  limitations 

c.  Demographic  limitations 

d.  Requirements  for  reduced  manning 

e.  Constraints  on  crew  size  and  mix 

2.  Personnel  Availability 

a.  Personnel  availability  estimates  by  skill  level  and  source 

b.  Budget  limitations 

3.  Human  Capability /Training  Issues  and  Constraints 

a.  Minimum  skill  level  projection 

b.  Constraints  on  personnel  progression 

c.  Constraints  on  training  equipment  and  facilities 
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d.  Requirements  for  special  skills  and  cross  training,  embedded  training,  training 
devices,  and  training  media 

4.  Human  Performance  Issues  and  Constraints 

a.  Minimum  acceptable  human  error  rates 

b.  Compatibility  with  and  effects  of  automation  on  human  skills  and  performance 

c.  Team  performance  requirements 

d.  Human  performance  limitations  and  capabilities  as  a  function  of  proposed  human- 
system  interfaces  (e.g.,  the  effects  and  interaction  of  human  fatigue  and  nuclear, 
biological,  and  chemical  (NBC)  protective  equipment  on  human  performance, 
system  design,  and  manpower) 

5.  System  Safety  and  Health  Issues  and  Constraints 

a.  Environmental  constraints 

b.  Limits  to  be  placed  on  environmental  factors 

c.  Biomedical  constraints 

d.  Habitability  constraints 

Section  4  —  HSI  Program.  This  section  includes  activities,  strategy,  analyses  results,  test  and 

evaluation,  and  relationships 

1.  HSI  activities  are  those  actions  required  for  each  acquisition  phase.  Examples  include 

the  following: 

a.  Reductions  in  positions  or  requirements  resulting  from  automation,  design 
improvements,  or  cross  training,  expressed  either  in  absolute  terms  or  as 
compared  with  the  predecessor  system 

b.  No  increase  in  the  characteristics  and  skills  of  operators,  maintainers,  or 
supporters;  quantitative  goals  for  personnel  capabilities 

c.  No  increase  in  training  hours  from  the  predecessor  system;  use  of  advanced 
training  technology  or  techniques,  e.g.,  embedded  training,  intelligent  tutoring, 
or  interactive  courseware  training  systems 

d.  Establishment  of  an  HFE  program 

e.  Establishment  of  system  safety  and  health  hazard  control  programs 
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2.  HSI  Strategy  —  This  section  reflects  the  system  acquisition  strategy  and  addresses  the 
following: 

a.  HSI  risk  assessment  and  reduction 

b.  Application  of  advanced  technology  in  the  achievement  of  HSI  objectives 

c.  Reliance  on  commercial  standards  and  data  (e.g.,  American  Society  for  Testing 
Materials  (ASTM)) 

d.  Establishment  of  HSI  priorities 

e.  Description  of  the  process  to  be  implemented  to  ensure  that  HSI  objectives  are 
met 

f.  Description  of  the  approach  for  addressing  HSI  issues  throughout  the  acquisition 
process 

3.  HSI  Analyses  —  This  indicates  the  analyses  to  be  conducted  and  their  effects  on 
managing  HSI  risks.  Annex  Tab  C  contains  information  on  data  sources  and  includes 
the  following  types  of  analysis  as  examples: 

a.  MAPTIDES 

b.  Test  Analysis 

c.  Human  Engineering  Analysis 

d.  System  Safety  Analysis 

e.  Analysis  of  the  predecessor  system 

4.  HSI  Analyses  Results:  Impacts  on  Design  and  Risk  —  This  section  includes  a  summary 
of  the  results  of  MPT,  HFE,  SS,  HH,  and  other  analyses  accomplished  in  the  Cost 
Benefit  Analysis,  for  each  alternative  concept  or  design. 

5.  HSI  Test  and  Evaluation  —  This  is  the  definition  of  how  the  system  T&E  program  will 
assess  HSI  domains  in  each  phase  of  the  acquisition  process. 

6.  HSI  Relationships  —  This  section  defines  how  HSI  is  organized  within  the  acquisition 
program,  how  HSI  will  interact  with  the  ILS  and  system  engineering  design  programs, 
and  a  discussion  of  specific  program  relationships  among  the  HSI  domains. 

Section  5  —  HSI  Tasks.  These  are  the  specific  HSI  Program  tasks  tailored  for  each  acquisition. 
This  section  includes  a  description  of  each  HSI  Program  task  in  terms  of: 

1.  The  specific  tasks  to  be  performed  for  this  procurement 
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2.  Required  resources  to  complete  each  task  -  both  funding  and  personnel 

3.  Time  to  complete  each  task 

4.  Responsible  organization 

5.  Support  organizations  and  their  specific  support  being  provided 

6.  Task  flow  dependencies  (i.e. ,  which  tasks  must  be  completed  before  others) 

Section  6  —  Products.  A  tailored  listing  of  all  HSI  products,  with  descriptions  of  each  HSI 
product  in  terms  of: 

1.  Related  task  that  produced  the  product  from  Section  5  above 

2.  Schedule  for  producing  each  product 

3.  Review  authority 
Section  7  —  Tabs 

Tab  A  —  HSI  Points  of  Contact:  List  of  activities  needed  for  HSI  information  and  assistance, 
including  the  activities  identified  in  Activities  Involved  section  and  those  responsible  for  HSI 
tasks. 

Tab  B  —  HSI  Milestone  Schedule:  Display  of  HSI  tasks  and  products  with  schedule 
relationships  to  the  acquisition  process  and  the  funding  process. 

Tab  C  —  References  and  Data  Sources:  Listing  of  references  and  data  sources  used  for  the  HSI 
effort;  examples  include  acquisition  documents  (MNS,  ORD,  AP),  T&E  documentation,  HSI 
data,  predecessor  and  comparable  systems  analyses,  and  new  technology  descriptions. 

Tab  D  —  HSI  Issues:  List  of  issues  that  will  influence  HSI  decisions.  Includes  a  description 
of  each  issue,  the  responsible  activity,  proposed  resolution  date,  and  status. 

Tab  E  —  Target  Audience  Description  (TAD):  Addresses  quantity,  quality,  and  performance 
capabilities  of  future  active  duty/reserves/civilians/contractors  who  will  operate,  maintain,  and 
support  the  new  acquisition  system. 

1.  The  TAD  is  based  on  a  compilation  of  requirements  in  each  Coast  Guard  rating  or 
officer  specialty  needed  and  similar  civilian  description  of  probable 
operators/maintainers/support  personnel  of  this  specific  system. 

2.  It  includes  the  numbers  of  people  available  now  and  expected  in  the  future,  aptitude 
scores  required,  mental  category  breakout,  physical  requirements,  training  currently 
provided,  and  high-driver  tasks. 
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Tab  F  —  Predecessor  System(s):  Defines  the  predecessor  system(s)  as  well  as  delineates  HSI 
lessons  learned  and  high  drivers  from  predecessor  systems. 

Tab  G  —  HSI  History  or  Audit  Trail:  Discussion  of  program  decisions  and  events  that  have 
affected  HSI  in  this  specific  acquisition.  Significant  HSI-related  decisions  made  during  all 
phases  of  the  acquisition  process  should  be  documented. 
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Appendix  F 

Key  HFE  Issues  in  HSI  Requirements  Development 

1.  What  effect  does  human  performance  have  on  system  reliability? 

2.  Are  the  controls  and  displays  laid  out  in  a  reasonable  manner? 

3.  Does  the  system  impose  severe  mental  or  physical  demands  on  the  operators? 

4.  Are  emergency  and  warning  signals  adequate  for  catching  the  attention  of  the  operators? 

5.  If  the  item  under  development  is  a  subsystem,  how  does  it  affect  the  operation  of  other 
subsystems. 

6.  Are  the  controls  and  displays  labeled  adequately? 

7.  Are  the  controls  laid  out  so  that  inadvertent  activation  will  not  cause  any  major 
problems? 

8.  Are  there  Atmospheric  conditions  that  could  affect  the  performance  of  the  user-machine 
system? 

9.  Is  there  adequate  lighting? 

10.  Does  the  operator  need  any  special  clothing  or  equipment  to  operate  the  system? 

11.  Is  the  system  documentation  written  at  a  level  that  could  be  understood  by  the  users? 

12.  Will  vibration  or  acceleration  have  an  adverse  effect  on  system  performance? 

13.  Are  the  control  dynamics  matched  with  human  capabilities? 

14.  How  will  protective  clothing  affect  the  operation  of  the  system? 

15.  What  are  the  maximum  impulse,  noise,  and  blast  overpressure  levels  that  can  be  expected 
from  this  system? 

16.  Do  the  weights  of  any  components  that  must  be  carried  by  Coast  Guardsmen  exceed 
applicable  standards? 

17.  Are  components  that  must  be  carried  properly  designed(e.g.,  have  adequate  handles?) 
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18.  Does  the  system  have  room  for  stowage  of  the  items  necessary  for  extended  surge 
operations? 

19  Does  the  proposed  system  involve  the  introduction  of  a  new  technology? 

20.  HFE  issues  consider  the  capabilities  and  performance  of  user-machine  combinations. 
Application  of  HFE  in  the  design  process  involves  consideration  of  HFE  issues  including 
but  not  limited  to: 

a.  Ingress/Egress 

b.  Seating/Crew  Station  Geometry 

c.  Open/Closed  Hatch  Vision 

d.  Controls/Displays 

e.  Lighting 

f.  Environmental  Control 

g.  Crew  or  Unit  Maintenance 
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APPENDIX  G 


Key  SS/HH  Issues  in  HSI  Requirements  Development 


MIL-STD-882B,  System  Safety  Program  Requirements,  is  the  seminal  document  that  defines 
the  key  SS/HH  domain  issues  that  should  be  considered  across  the  system  development  life- 
cycle.  These  requirements  consist  of  two  distinct  classes  of  tasks  that  can  be  imposed  on 
contractors  on  in-house  development  efforts  that  can  be  effectively  tailored  to  Coast  Guard 
acquisitions:  (1)  Program  Management  and  Control  tasks  (Tasks  100  -  108),  and  (2)  Design 
and  Evaluation  tasks  (Tasks  210-213). 

1.  Program  Management  Tasks 


Task 

100 

101 

102 

103 

104 

105 

106 

107 

108 


Title 

System  Safety  Program 

System  Safety  Program  Plan 

Integration/Management  of  Associate  Contractors, 
Subcontractors,  and  Architect  and  Engineering  Firms 

System  Safety  Program  Reviews 

System  Safety  Group/System  Safety  Working  Group  Support 

Hazard  Tracking  and  Risk  Resolution 

Test  and  Evaluation  Safety 

System  Safety  Progress  Summary 

Qualifications  of  Key  Contractor  System  Safety 
Engineers/Managers 


2.  Design  and  Evaluation  Tasks 


Tasks 

201 

202 

203 

204 

205 


Title 

Preliminary  Hazard  List 
Preliminary  Hazard  Analysis 
Subsystem  Hazard  Analysis 
System  Hazard  Analysis 
Operating  &  Support  Hazard  Analysis 
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206  Occupational  Health  hazard  Analysis 

207  Safety  Verification 

208  Training 

209  Safety  Assessment 

210  Safety  Compliance  Assessment 

211  Safety  Review  of  ECPs  and  Waivers 

212  —  Reserved  — 

213  GFE/GFP  System  Safety  Analysis 
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MANPOWER  ESTIMATE  REPORT  (FORMAT)1 
(Program  Title) 
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Provide  separate  estimates  by  Active  and  Reserve  Components. 

Begin  with  initial  production  and  continue  through  full  operational  deployment.  Estimates  should  be  cumulative  from  fiscal  year  to  fiscal  year. 
Provide  estimates  for  required  billets/positions  (or  man-years  for  contractors)  for  each  fiscal  year. 
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MPT  CONCEPT  DEVELOPMENT  FORMAT 


Part  I 

A.  Introduction 

B.  System  Description  (functional  and  physical) 

C.  System  Requirements 

D.  Concept  Summaries 

E.  Performance  Goals  and  Standards 

F.  E/S/S  Equipment  and  Functions 

G.  External  Interfaces 

H.  E/S/S  Configurations 

I.  Installation  Schedule 

Part  II 

A.  Introduction 

B.  Manpower  concept  for  E/S/S  configuration(s)  per  representative  platform/activity 

1.  Maintenance  manpower 

a.  Organizational  level 

b.  Intermediate  level 

c.  Depot  level 

d.  Other  maintenance  manpower 

2.  Operator  manpower 

a.  Operator 

b.  Operator/maintainer 

3.  Other  manpower  (by  activity) 
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APPENDIX  J 


NMRS  MANPOWER  PRODUCTS 

The  Navy  Manpower  Requirements  System  (NMRS)  produces  two  principal  products  related  to 
development  of  the  Vessel  Manpower  Document  (VMD).  These  are  the  NMRS  working  papers 
and  the  VMD  itself.  The  working  papers  provide  a  summary  of  system  inputs,  functional 
transactions,  variability  factors,  preliminary  billet  estimates  and  billet  development,  and  watch 
station  requirements.  All  NMRS  manpower  products  are  machine  generated.  For  additional 
information  on  NMRS  manpower  products,  refer  to  OPNAVINST  5310.19,  Appendix  C. 


WORKING  PAPERS  (VESSEL  MANPOWER  DOCUMENTS) 


Section  I 
Section  n 
Section  HI 
Section  IV 
Section  V 


-  Workload AV atch  Input  Records 

-  History  of  Workload/Watch  Transactions 

-  History  of  Standard/Variability  Transactions 

-  Workload  Distribution  Report  by  Organization 

-  Watch  Station  Assignments 


VESSEL  MANPOWER  DOCUMENT  (VMD) 


Forward 

1.  Introduction 

2.  Projected  Operational  Environment  (POE) 

3.  Required  Operational  Capabilities  Statement  (ROC) 

4.  Definition  of  Terms 

A.  Organizational  Manning 

B.  Operational  Manning 

(1)  Conditions  of  Manning  Readiness 

(2)  Special  Conditions 

(3)  Functional  Readiness 

(4)  Condition  Watches 

C.  Maintenance  Manpower  Requirements 

(1)  Planned  Maintenance  (PM) 

(2)  Corrective  Maintenance  (CM) 

(3)  Facility  Maintenance  (FM) 

D.  Own  Unit  Support  Manpower  Requirements  (OUS) 
(1)  Administrative  Support 
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(2)  Command  Support 

(3)  Supply  Support 

(4)  Medical  Support 

(5)  Utility  Task  and  Evolution 

E.  Customer  Support  Manpower  Requirements  (CS) 

F.  Manpower  Factors 

(1)  Productive  Allowance  Factor  (PA) 

(2)  Service  Diversion  Allowance  and  Training  (SD&T) 

TAB  A  Doctrinal  Constraints 

TAB  B  Navy  Standard  Workweek  Afloat 

5.  Document  Sections  (Draft  Format) 

SECTION  I  —  Officer  Billet  Summary 

Billet  Sec  Number 
Billet  Title 
Officer  Rank 
Officer  Designator 

Primary  Naval  Officer  Billet  Classification  (NOBC) 

Secondary  NOBC 
Sub  Specialty  Code 

Additional  Qualification  Designator/Utilization  Code  (ADD/U) 

SECTION  II  —  Manpower  Summary 

Major  Organizational  Component 
Number  of  Officers 
Number  of  Enlisted 
Number  of  Civilian 

SECTION  III  —  Manpower  Requirements 

Billet  Sequence  Number 
Billet  Title 
Sub  Specialty  Code 
AQD/U 

Officer  Designator/Minimum  Rate/Rating  for  Billet 
Primary  NOBC 
Secondary  NOBC 
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SECTION  IV  -  Battle  Bill 


Watch  Station  Number 
Station  Identification 
Condition 

-  Division 

-  Minimum  Rating  and  Paygrade 

-  NEC 

SECTION  V  —  Functional  Workload 
Function 

Functional  Hours  Required 
OMW  Hours  Available 
OMW  Hours  Used 
Functional  Hours  Distributed 

SECTION  VI  (Part  01)  —  Summary  of  Officer  Manpower  Requirements 

Designator 

Paygrade 

SECTION  VI  (Part  02)  —  Summary  of  Enlisted  Manpower  Requirements 

Rating  Group 
Primary  NEC 
Secondary  NEC 
Paygrade 

SECTION  VI  (Part  2a)  —  Summary  of  Enlisted  Manpower  Requirements  by  Dept. 

Division 

Rating 

Primary  NEC 
Secondary  NEC 
Paygrade 

SECTION  VII  —  Summary  of  Organizational  Manpower  Requirements 
(1)  Organizational  Manpower  Requirements 

-  Officer 

-  CPO 

-  Other  Enlisted 
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(2) 


General  Apportionment  of  Enlisted  Skills 


-  Petty  Officers 

-  Designated  Strikers 

-  Non-Rated  Personnel 

(3)  Paygrade  Distribution 


Appendices 

Appendix  A  Part  1  Maintenance  Requirements/Table  of  Equipment  Analysis 

Part  II  Summary  of  PM  Requirements  by  Division/Rating/ 
Rate/NEC. 
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APPENDIX  K 


DETERMINATION  OF  DELTAS 


Comparability  analysis  is  based  upon  the  determination  of  differences  between  the  BCS  and  the 
new  E/S/S,  and  how  these  differences  affect  the  requirements  for  MPT  resources  created  by  the 
new  E/S/S.  These  differences  are  the  sources  of  change  in  MPT  requirements  between  the  BCS 
and  the  new  E/S/S.  Deltas  are  the  estimated  changes  in  BCS  values,  and  their  determination  is 
central  to  effective  comparability  analysis. 

A  delta  is  calculated  according  to  the  following  formula: 

Delta  Value  =  Existing  BCS  Value  x  Change  Factor 

The  change  factor  is  the  anticipated  value  of  the  difference  between  the  BCS  and  the  new  E/S/S. 
This  could  be,  for  example,  a  10%  increase  in  reliability  or  a  30%  decrease  in  operating  time. 

In  essence,  the  analyst  is  called  upon  to  develop  deltas  for  each  area  of  MPT  analysis 
appropriate  to  the  program  employing  the  MANT1DES  Methodology.  Each  delta  is  determined 
based  on  the  logical  extension  of  the  differences  between  the  BCS  and  the  new  E/S/S.  There 
is  no  hard  and  fast  rule  for  developing  deltas.  The  objective  is  to  use  the  existing  BCS  value(s) 
and  to  determine  an  appropriate  change  factor.  The  change  factor  should  reflect  the  way  in 
which  the  BCS  value  is  stated  and  the  variety  of  physical  features,  design  features,  and  system 
concepts  inherent  in  the  new  E/S/S.  In  order  to  assist  the  analyst  in  understanding  how  deltas 
may  be  determined,  several  examples  are  given  below.  This  is  followed  by  a  discussion  of 
considerations  that  the  analyst  should  be  aware  of  in  developing  deltas. 

EXAMPLES  OF  DELTAS 


Example  No.  1 

For  purposes  of  this  example,  let  us  assume  that  the  deltas  we  are  determining  result  from 
anticipated  mission  differences  between  the  BCS  and  the  new  E/S/S.  In  addition,  let  us  assume 
that  the  BCS  is  operated  only  at  general  quarters,  while,  as  a  result  of  the  mission  difference, 
the  new  E/S/S  will  be  operated  24  hours  a  day.  As  a  result  of  these  differences,  maintenance 
deltas  and  operator  skill  deltas  will  have  to  be  determined. 

Maintenance  Deltas 

Deltas  may  be  determined  for  all  areas  of  MPT  analysis. 

Preventive  Maintenance  (PM)  deltas  may  be  determined  in  one  of  two  ways,  dependent  upon 
how  PM  requirements  are  stated.  If  PM  requirements  are  stated  as  a  function  of  operating  hours 
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then  a  delta  is  determined  based  upon  a  change  to  operating  hours.  For  example,  if  the  current 
mission  requires  the  system  to  operate  20  hours  per  week,  with  a  requirement  for  0. 1  hours  of 
PM  per  operating  hour,  then  the  current  PM  requirement  is  two  hours  per  week.  If  the  mission 
of  the  new  E/S/S  requires  24  hours  a  day,  7  days  a  week  operation  with  the  same  PM  to 
operating  hour  ratio,  a  PM  delta  must  be  calculated.  The  first  step  is  to  calculate  the  change 
factor.  In  this  case,  the  change  factor  equals  the  projected  operating  hours  divided  by  the 
existing  operator  hours. 

Change  Factor  =  168  hrs/wk  /  20  hrs/wk  =  8.4 

The  delta  is  then  calculated  to  equal  the  existing  PM  hours  per  week,  multiplied  by  the  change 
factor. 


PM  Delta  =  2  hrs/wk  x  8.4  =  16.8  hrs/wk 

The  new  PM  requirement  for  this  mission  change  would  then  be  16.8  hours  per  week. 

PM  requirements  may  also  be  established  based  on  a  cyclic  pattern  (i.e.,  weekly  or  monthly). 
Determination  of  deltas  in  this  case  is  more  subjective.  Confer  with  design  engineers  and  other 
subject  matter  experts  to  determine  if  the  cyclic  BCS  PM  schedule  is  satisfactory  for  the  new 
E/S/S.  If  not,  adjust  the  PM  schedule  to  reflect  the  collective  best  estimate. 

Corrective  Maintenance  (CM)  requirements  are  determined  based  on  two  factors,  mean  time 
between  failure  (MTBF)  of  the  equipment  and  mean  time  to  repair  (MTTR)  those  failures. 
Using  the  mission  change  example,  and  assuming  an  MTBF  of  60  operating  hours,  the  CM  delta 
would  be  calculated  in  the  following  manner. 

Existing  CM  actions  per  week  equals  existing  operating  time  divided  by  MTBF. 

20  operating  hrs/wk  /  60  operating  hours  =  0.33  existing  CM  actions/wk 

The  CM  delta  is  then  equal  to  the  existing  CM  value  multiplied  by  the  change  factor.  The 
change  factor  as  determined  above  is  8.4. 

C  Delta  -  0.33  CM  actions/wk  x  8.4  =  2.8  CM  actions/wk 

CM  hours  required  are  then  calculated  by  multiplying  the  number  of  CM  actions  per  week  by 
the  MTTR. 

CM  hrs/wk  =  2.8  CM  actions/wk  x  1.35  hrs/CM  action  =  3.78  hrs/wk 

In  this  case,  the  new  value  would  be  3.78  CM  hours  per  week.  This  same  figure  could  be 
calculated  in  fewer  steps  by  multiplying  the  number  of  existing  CM  hours  per  week  by  the 
change  factor. 
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CM  Delta  =  0.45  CM  hrs/wk  x  8.4  =  3.78  CM  hrs/wk 

When  historical  CM  data  is  not  available,  use  an  overall  PM  to  CM  ratio  of  2:0,  except  for 
electronics,  where  a  1:1  ratio  is  used.  This  ratio  includes  CM-associated  make-ready  and  put- 
away  time. 

Operator  Skill  Deltas 

Operator  skill  deltas  do  not  lend  themselves  to  the  quantitative  analysis  depicted  above.  These 
changes  are  related  to  operator  skill  requirements  and  involve  a  qualitative  assessment  of  the 
suitability  of  existing  rates,  ratings,  and  special  skills  to  operate  in  the  modified  functional 
environment.  Operator  skill  related  deltas  should  be  determined  as  a  result  of  an  assessment  of 
skill  suitability  based  on  occupational  standards,  and  consultation  with  subject  matter  experts 
such  as  occupational  specialists  in  the  Office  of  Personnel  and  Training  and  rating  technical 
advisors. 

Example  No.  2 

Deltas  related  to  changes  in  design  and/or  technology  are  a  common  cause  of  changes  in  system 
related  MPT  requirements.  These  deltas  can  take  two  major  forms.  First  is  a  change  in  design 
and/or  technology  that  eliminates  existing  tasks  or  creates  new  tasks.  Second  is  a  change  in 
design  and/or  technology  that  modifies  existing  task  frequency  and/or  duration. 

When  tasks  have  been  eliminated,  identify  the  number  of  hours  required  per  week  to  perform 
that  task  and  reduce  the  existing  workload  requirements  by  that  value.  Ensure  that  work  load 
is  associated  with  the  proper  rate,  rating,  and  special  skills.  In  general,  the  only  instance  in 
which  an  entire  billet  requirement  will  be  deleted  is  when  a  watch  station  requirement  has  been 
eliminated. 

Added  tasks  create  a  more  complex  problem.  If  there  is  no  existing  task  with  available 
performance  data,  then  it  is  necessary  to  conduct  task  analysis.  Task  analysis  is  discussed  in 
Step  2  of  the  HARDMAN  Methodology  (OPNAV  P-111-1-87)  as  well  as  in  MIL-STD-1388-1A 
and  MIL-T-2905B,  and  is  beyond  the  scope  of  this  Appendix. 

Changes  to  design  and/or  technology  which  affect  the  duration  or  frequency  of  existing  tasks  are 
calculated  in  much  the  same  manner  as  described  for  PM  and  CM  tasks  affected  by  mission 
changes.  The  two  principal  factors  which  are  used  to  denote  these  changes  are  reliability  and 
maintainability.  Reliability  is  often  expressed  in  terms  of  MTBF.  Thus  an  increase  in  reliability 
of  10  percent  would  increase  the  MTBF  by  10  percent.  In  this  case  the  change  factor  would  be 
1.1.  The  10  percent  is  added  to  the  unity  value  because  it  represents  an  increase  in  MTBF. 

Maintainability  is  often  expressed  in  terms  of  MTTR.  Thus  an  increase  in  maintainability  of  10 
percent  would  decrease  the  MTTR  by  10  percent.  In  this  case  the  change  factor  would  be  0.9; 
the  10  percent  factor  is  given  a  negative  value  because  it  represents  a  decrease  in  MTTR. 


The  equations  representing  both  a  10  percent  increase  in  reliability  and  a  10  percent 
improvement  in  maintainability  are  as  follows: 

MTBF  Delta  =  Existing  MTBF  x  1.1 

MTTR  Delta  =  Existing  MTTR  x  0.9 

It  is  important  to  note  that  changes  in  reliability  and  maintainability  may  not  always  be  applied 
to  the  entire  system,  but  rather  to  components  of  it.  If  changes  apply  only  to  a  component  of 
the  system  under  study,  then  deltas  are  calculated  only  for  tasks  associated  with  the  changed 
component.  These  revised  values  are  then  added  into  the  system  total  to  determine  the  overall 
affect  on  system  reliability  and  maintainability. 

For  example,  a  90  percent  improvement  in  reliability  of  a  system  component  does  not  equate  to 
a  90  percent  change  in  reliability  of  the  system  unless  that  component  accounts  for  100  percent 
of  system  failures.  If  the  component  only  accounts  for  20  percent  of  system  failures,  the  overall 
improvement  in  reliability  equals  only  18  percent  (.9  improvement  x  .2  of  system  failures  = 
.18).  Thus,  it  is  possible  for  a  25  percent  improvement  in  reliability  of  a  component,  which 
accounts  for  90  percent  of  system  failures,  to  have  greater  impact  on  system  reliability  than  an 
80  percent  improvement  for  a  component  which  accounts  for  only  five  percent  of  svstem 
failures. 

The  analyst  must  ensure  that  such  deltas  are  applied  only  to  the  proper  tasks.  Improved 
maintainability  may  reduce  the  duration  of  some  maintenance  tasks;  however,  it  is  most  unlikely 
that  make-ready  and  put-away  time  would  be  affected.  All  system  deltas  must  be  calculated  with 
respect  to  individual  tasks  and  then  aggregated  into  a  new  system  total 

CONSIDERATIONS  IN  DEVELOPING  DELTAS 
PHYSICAL  FEATURES 

1.  Size,  weight,  volume,  number  of  units,  etc.:  What  are  the  changes  made  in  this  area? 
The  number  of  personnel  per  task  may  be  affected  when  considering  the  logistics  of 
transporting  or  otherwise  physically  handling  the  units  during  operation  or  maintenance. 

2.  Location:  Where  are  the  subsystem  units  physically  located?  The  number  of  personnel 
required  to  maintain  or  operate  the  subsystem  may  be  affected  if  the  units  are  spread  out. 
Time  to  troubleshoot  and/or  repair  is  affected  by  accessibility. 
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DESIGN  FEATURES 


Electronic  Design 

1 .  New  devices/components:  What  is  the  electronic  state-of-the-art  proposed  for  the 
new  subsystem?  What  is  the  level  of  internal  functional  integration?  The 
reliability  or  mean  time  between  failures/corrective  maintenance  actions  for  the 
subsystem  unit  is  often  driven  by  the  individual  component  reliabilities. 
Furthermore,  maintenance  concept  and  skill  level  may  be  affected. 

2.  Digital/analog:  What  functions  are  digital  or  analog?  What  are  the  interfaces? 
Reliability  may  be  affected  by  changes  in  this  area  (e.g.,  digital  circuitry  is  often 
more  reliable  than  analog).  Digital  circuitry  is  generally  more  adaptable  to 
modular  design,  which  may  result  in  faster  and  easier  remove  or  replace  actions. 
Planned  maintenance  time  may  be  reduced  by  using  digital  circuits  because  analog 
devices  often  require  more  adjustment/alignment  and  performance  checks. 
Troubleshooting  time  may  be  reduced  because  of  the  "go/no-go"  aspects  of  digital 
circuits. 

3.  Modularity:  What  is  the  level  of  modular  construction?  What  percentage  of  the 
subsystem/unit  is  modular?  To  what  extent  is  the  modularity  standardized? 
Repair  time  may  be  reduced  by  increased  modularity  and  standardization  of 
modules  and  through  increased  use  of  remove/replace  actions  at  the  module  rather 
than  at  the  component  level.  Troubleshooting  times  may  decrease  because  it  often 
takes  less  time  to  isolate  faults  at  the  function/module  level  than  at  the  component 
level. 

Mechanical  Design 

1.  Accessibility:  How  long  does  it  take  operational/maintenance  personnel  to  open 
inspection  ports  or  to  get  into  a  unit?  Operating  delays  and  maintenance  times 
may  be  affected  by  accessibility. 

2.  Complexity  of  moving  major  assemblies:  What  type  of  support  equipment  is 
required  to  move  units?  How  easy  is  it  to  set  up?  To  use?  Maintenance  times 
are  the  hours  required  to  perform  the  repair,  plus  any  support  equipment  manning 
required.  In  such  cases,  the  number  of  people  required  for  the  task  may  be 
affected.  Skill  levels  may  be  impacted. 

3.  Tolerances:  How  many  procedures  require  alignment/adjustment  to  a  given 
tolerance?  How  critical  are  the  tolerances?  How  easy  is  it  to  achieve  the  given 
tolerance  specifications?  Corrective  and  planned  maintenance  times  as  well  as 
operating  delays  may  be  affected.  Skill  levels  also  may  be  affected. 


General  Design  Characteristics 

1.  Special  tools:  What  special  tools  are  required?  How  complex  are  they  to  use? 
Troubleshooting,  repair,  and  preventive  maintenance  times  may  be  affected.  Skill 
levels  required  may  also  be  affected. 

2.  Special  purpose  test  equipment  (SPTE):  What  SPTE  is  required?  How  complex 
is  it  to  use?  What  are  its  capabilities?  Skill  levels  and  maintenance  times  may 
be  affected. 

3.  Built  in  test  equipment  (BITE):  What  BITE  exists?  What  are  its  capabilities? 
How  long  to  test?  How  effective  is  it?  Higher  skill  levels  are  often  required 
where  BITE  does  not  exist.  Troubleshooting  time  may  be  reduced  by  increasing 
the  BITE  capabilities.  The  number  of  people  required  to  maintain  a  subsystem 
could  be  a  function  of  BITE  if  the  units  are  diversely  and  remotely  located. 

SYSTEM  RELATED  CONCEPTS 

Interface/Intercommunications 

1.  Software:  How  compatible  is  software  between  the  subsystems?  Software 
compatibility  permits  easier  intercommunication  between  subsystems  and  possible 
function  sharing.  This  may  affect  the  number  of  operators  required. 

2.  System  hardware  integration:  To  what  extent  do  various  subsystems  share 
hardware  functions  such  as  controls  and  displays?  Increased  integration  may  lead 
to  reductions  in  the  number  of  operators  because  fewer  operators  can  monitor  and 
control  more  units  from  one  location.  Similarly,  increased  integration  reduces  the 
absolute  numbers  of  units  that  might  fail,  thus  permitting  reductions  in  overall 
maintenance  time  or  number  of  maintainers.  Also,  an  improvement  in  system 
reliability  is  possible. 

3.  Central  integrated  test  system  (CITS):  To  what  extent  does  CITS  exist?  What 
are  its  capabilities?  CITS  is  conceived  to  be  capable  of  monitoring  the  individual 
subsystem  BITEs  as  well  as  possible  signal/data  degradation.  It  is  centrally 
located,  and  when  tied  in  with  hardware  and  software  integration  concepts,  may 
allow  for  a  further  reduction  in  personnel  and  a  small  increase  in  availability. 

4.  Computer  aided  maintenance/instruction  (CAM/I):  To  what  extent  does  this 
exist?  CAM/I  may  reduce  troubleshooting  time  by  providing  semi-automated 
logical  and  procedural  troubleshooting  aids.  CAM/I  can  also  help  to  reduce  skill 
levels  required  for  maintainers  and  operators. 
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5. 


Bussing:  What  type  of  bus  system  exists?  Bussing,  as  opposed  to  traditional 
dedicated  interconnections,  allows  for  increased  system  integration.  It  permits  a 
reduction  in  the  number  and  complexity  of  wire  runs.  If  fiber  optic  bussing 
techniques  are  used,  interference  problems  are  greatly  reduced.  In  either  case, 
bussing  increases  subsystem  reliability  and  reduces  maintenance  times. 

Maintenance  Concept 

The  maintenance  concept  must  be  reviewed  in  sufficient  detail  to  permit  identification  of 

task  requirements  of  personnel  responsible  for  the  subsystem. 

1.  Organizational:  What  is  the  maintenance/sparing  concept  at  the  organizational 
level?  This  concept  affects  maintenance  times,  skill  levels,  and  numbers  of 
personnel  required. 

a.  Planned  maintenance  (PM):  What  are  the  PM  requirements?  (e.g., 
servicing,  cleaning,  lubricating,  adjusting,  etc.).  How  are  the  PMs 
instructed/performed?  (e.g.,  proceduralized  guides  or  manuals  and 
training,  etc.).  How  complex  are  the  procedures?  (e.g.,  are  alignment 
or  calibration  procedures  required?) 

b.  Corrective  maintenance  (CM):  How  is  a  subsystem  malfunction  detected? 
Is  it  at  organizational  level  or  IMA/Depot  level?  If  the  replacement  is 
repaired  at  the  organizational  level,  how  is  the  failed  part  isolated?  To 
what  level?  Are  automated  test  equipment,  manual  test  equipment, 
general  purpose  test  equipment  and  schematics,  or  proceduralized  aids 
used?  What  special  tools,  skills,  and  knowledges  are  required  to  perform 
the  repairs? 

2.  Intermediate:  What  is  the  maintenance  philosophy  for  the  given  subsystem  at  this 
level?  Turn-around  times,  number  of  personnel,  and  skill  levels  may  be  affected. 
Are  any  repair  functions  performed?  If  so,  refer  to  the  guide  for  organizational 
level  maintenance.  Is  maintenance  assistance  to  be  provided  to  the  organizational 
personnel  from  the  IMA?  Are  IMA  personnel  required  to  have  more  in-depth 
knowledge  of  the  subsystem  or  electronic  principles?  Does  the  IMA  function  as 
a  supply  (logistics)  source  for  the  organizational  level?  What  other  functions  does 
the  IMA  provide  for  subsystem  support  (e.g.,  calibration,  alignment,  special 
tools,  etc.)? 

3.  Depot:  What  functions  does  the  depot  activity  provide  in  support  of  the 
subsystem?  Are  Navy,  civil  service  or  contractor  personnel  involved?  Are 
training  programs  required?  If  so,  these  must  be  assessed  in  terms  of  the  tasks 
performed  and  the  skills  and  knowledge  required  to  perform  the  tasks.  What 
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support  (spares,  etc.)  does  the  depot  provide  for  the  subsystem  and  what  are  the 
resultant  manpower  needs? 

Operations  Concept 

The  operational  manning  concept  must  also  be  reviewed  to  identify  the  subsystem  task 
requirements.  Does  the  subsystem  require  operational  manning?  What  is  the  manning 
frequency/period?  What  are  the  operational  tasks  and  operator  skill  levels  required? 
How  is  the  subsystem  operated  (e.g.,  remote  or  local)?  Is  more  than  one  location  used 
simultaneously?  What  is  the  operator  task  loading  and  what  are  the  human  engineering 
factors? 


APPENDIX  L 


HSI  JOINT  WORKING  GROUP 

1.  As  needed,  the  OHSIP  should  form  a  Coast  Guard  HSI/Joint-Working  Group  (JWG)  to 
advise  on  all  aspects  of  identifying,  analyzing,  resolving,  and  documenting  HSI  issues 
encountered  in  meeting  the  goal  of  fully  integrating  all  HSI  domains  into  each  system 
acquisition.  This  joint  working  group  is  made  up  of  Coast  Guard  organizations  that  may  not 
otherwise  be  directly  involved  in  the  acquisition  process,  but  who  have  expertise  and  data 
applicable  to  one  or  more  HSI  domains.  Inputs  from  such  organizations  are  invaluable  to 
OHSIP  in  attempting  to  focus  the  most  rigorous  advise  available  to  the  Coast  Guard  in  making 
long-range  predictions  and  projections  concerning  HSI  domain  issues  in  individual  acquisitions. 

2.  The  exact  composition  of  the  working  group  is  based  on  assets  available  and  the  type  of 
acquisition  conducted  (e.g.,  the  design  and  development  of  information  resource  management 
equipment  would  require  a  different  membership  than  the  acquisition  of  a  helicopter  or  a  cuter). 
Membership  should  be  selected  from  the  following  organizations: 

a.  Office  Responsible  for  HSI  Program  —  Convenes  as  required  and  Co¬ 
chairs  the  HSUWG 

b.  Sponsor  —  Co-chairs  HSUWG  when  convened 

c.  Human  Factors  Engineering  Proponent 

d.  Manpower  Proponent 

e.  Personnel  Proponent 

f.  Training  Developer 

g.  System  Safety/Health  Hazards  Proponent 

h.  Integrated  Logistics  Support  (ILS)  Developer 

i.  Project  Manager  (PM) 

j.  Other  organizations  as  appropriate 

3.  Interface  between  OHSIP  and  HSUWG.  When  the  joint  working  group  is  formed  for  an 
acquisition,  the  OHSIP  uses  assigned  domain  expertise  and  does  most  of  the  HSI  planning, 
analyses,  testing,  and  follow-up  with  assistance  as  needed  from  the  HSUWG. 


Responsibilities  for  HSI 


(1)  The  HSUWG  supports  the  HSI  Program  by: 

a.  Assisting  OHSIP  as  requested  in  identifying,  analyzing,  resolving, 
and  documenting  all  HSI  issues  in  each  acquisition. 

b.  Bringing  together  institutional  organizations  who  maintain  data 
bases  hand  have  functional  expertise  that  may  be  needed  by  OHSIP 
to  properly  execute  the  HSI  Program.  The  joint  working  group 
provides  a  forum  to  coordinate  access  to  this  information  and 
expertise;  it  also  provides  a  forum  with  all  the  appropriate  staff 
experts  as  members  to  review  and  advise  on  plans  and  completed 
analyses  and  to  assess  impacts  on  the  total  Coast  Guard,  etc. 

(2)  The  OHSIP  supports  the  HSI  Program  by:  Refer  to  OHSIP  responsibilities 

in  Section  C  under  paragraph  4.1.a.(2).  In  addition,  OHSIP  provides 

training  to  the  HSIJWG  when  the  group  is  formed  and  for  any  new 

members. 

Exchange  of  Necessary  Information/Data/Documents/Etc. 

(1)  Inputs  from  the  HSIJWG  to  OHSIP 

(a)  Program  guidance  and  constraints  known  to  joint  working  group 
members  that  impact  HSI  domains 

(b)  Data  from  members  with  institutional  data  bases,  such  as 

manpower  planning  data  and  personnel  data  describing 
characteristics  for  use  in  the  TAD  and  the  amount/kind  of  training 
currently  received  by  ratings/pay  grades  of  interest,  etc. 

(c)  Review  HSI  plans,  completed  analyses,  and  other  HSI 
documentation  as  requested 

(2)  Inputs  from  OHSIP  to  the  HSUWG 

(a)  OHSIP  convenes  and  acts  as  co-chair  of  the  HSIJWG 

(b)  OHSIP  submits  HSI  plans,  analyses,  and  documentation  to  the 

HSIJWG  for  review  as  required 


Coordination/Communications  Required 


(1)  OHSIP  is  the  principal  participant  in  setting  up  the  HSUWG,  developing 
the  agenda,  and  coordinating  all  activities  of  the  group. 

(2)  As  requested,  the  HSUWG  reviews  and  provides  feedback  to  OHSIP  on 
the  adequacy  of  all  HSI  plans,  studies,  analyses,  and  documentation. 


